ThreadPriorityPolicy settings for non-root users

Fri Dec 21 13:38:06 UTC 2018

>If you want to just disable the root check to get back the erroneous 
>ThreadPriorityPolicy=2 behaviour then file a bug and a CSR and propose a 
>patch. I don't think we want yet another flag for this though. Just drop 
>the root check for ThreadPriorityPolicy=1 and let the underlying system 
>permissions control success or failure.

Hi David, I think we will go this way !
 ( However  not  the root check made the special case  ThreadPriorityPolicy=2   fail,  but the added  range check  for  ThreadPriorityPolicy  in globals.hpp  ( 8122937 )
 which introduced  range(0, 1)   ) .

Best regards, Matthias

> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Freitag, 21. Dezember 2018 13:47
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; 'hotspot-dev at openjdk.java.net' <hotspot-
> dev at openjdk.java.net>
> Subject: Re: ThreadPriorityPolicy settings for non-root users
> 
> On 21/12/2018 9:24 pm, Lindenmaier, Goetz wrote:
> > Hi David,
> >
> > Yes, as Matthias stated we have at least one application that relies on
> > thread priorities. Their going to Java 11 is blocked by this.
> 
> I'd like to hear more. I'd be very surprised that any actual functional
> correctness issue is addressed by playing with niceness.
> 
> > Also are you aware that this is the implementation of Thread.setPriority()?
> 
> There are no specified semantics for Thread priorities in Java, as they
> pertain to operating system priorities, or relative scheduling across
> processes. So there is nothing broken with regard to the specification
> with the default behaviour (ThreadPriorityPolicy=0).
> 
> > So isn't it great we finally fix the old and bit-rotten code that implements
> > this official method?
> 
> No. Thread priorities are a minefield. Giving threads priorities was one
> of the biggest mistakes in the Java thread API. People were advised to
> just forget about them 20+ years ago - and most took that advice. I
> think the only reason this wasn't all stripped out years ago was some
> corner cases with Solaris scheduling classes.
> 
> If you want to just disable the root check to get back the erroneous
> ThreadPriorityPolicy=2 behaviour then file a bug and a CSR and propose a
> patch. I don't think we want yet another flag for this though. Just drop
> the root check for ThreadPriorityPolicy=1 and let the underlying system
> permissions control success or failure.
> 
> David
> 
> > Best regards,
> >    Goetz.
> >
> >
> >> -----Original Message-----
> >> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf
> Of
> >> David Holmes
> >> Sent: Freitag, 21. Dezember 2018 11:56
> >> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> >> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> >> Subject: Re: ThreadPriorityPolicy settings for non-root users
> >>
> >> On 21/12/2018 6:39 pm, Baesken, Matthias wrote:
> >>> Hi  David  ,   it might be  that  the functionality  is  seen as not very helpful
> >> by some and removed  or deprecated  in  some future  Java release.
> >>>
> >>> However it is present in the current JDKs and should work there nicely .
> >>
> >> Sorry but that's a bit naive. The code is old and bit-rotted and in some
> >> cases (Mac port) likely never used, so the idea that "it's there so it
> >> should work" is just not realistic - sorry.
> >>
> >>> Currently  I have some points I do not like about the current state :
> >>>
> >>> - the root-check  is not consistent , it is present  on Linux /  BSD (Mac)
> but
> >> I don't see it on Solaris
> >>
> >> Wasn't needed on Solaris. User-level capabilities sufficed.
> >>
> >>> - It  ignores currently  the  CAP_SYS_NICE capability
> >>
> >> It never supported it. AFAIK the linux code doesn't really support any
> >> capability based permissions.
> >>
> >>> - it ignores that  setting a  higher niceness works nicely  on most OS
> >> (checked Linux/Solaris/BSD)  without being root  (or having special
> >> capabilities)
> >>
> >> The priority control was never really about tweaking niceness levels.
> >>
> >>> -  the root check makes testing hard  (maybe that's why the Mac version
> >> was a bit broken?)
> >>
> >> Running under sudo isn't that hard.
> >>
> >> Sorry I'm not very supportive here - this isn't something that needs
> >> some minor tweaking to bring back online, it's something that may never
> >> have worked well in the first place.
> >>
> >> Have you got real use cases for this?
> >>
> >> Cheers,
> >> David
> >>
> >>>
> >>> Best regards, Matthias
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: David Holmes <david.holmes at oracle.com>
> >>>> Sent: Donnerstag, 20. Dezember 2018 12:06
> >>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> >>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> >>>> Subject: Re: ThreadPriorityPolicy settings for non-root users
> >>>>
> >>>> Hi Matthias,
> >>>>
> >>>> The more I think about this the more I see it as a huge can of worms.
> >>>> There are very, very, limited usecases for managing the priority of
> >>>> individual threads within a running Java application. Adjusting the
> >>>> process priority/nice-ness is effective and much simpler.
> >>>>
> >>>> Cheers,
> >>>> David
> >>>>
> >>>> On 20/12/2018 3:13 am, Baesken, Matthias wrote:
> >>>>>
> >>>>> Hello ,
> >>>>>      currently OpenJDK supports 2 ThreadPriorityPolicy settings,  0
> >> (normal,
> >>>> the default) and 1,
> >>>>> the so called "aggressive" mode :
> >>>>>
> >>>>> "1 : Aggressive.                                                 "\
> >>>>> "    Java thread priorities map over to the entire range of      "\
> >>>>> "    native thread priorities. Higher Java thread priorities map "\
> >>>>> "    to higher native thread priorities. This policy should be   "\
> >>>>> "    used with care, as sometimes it can cause performance       "\
> >>>>> "    degradation in the application and/or the entire system. On "\
> >>>>> "    Linux this policy requires root privilege.")                 \
> >>>>>
> >>>>> Currently  we check directly for root in os_bsd.cpp and os_linux.cpp
> (the
> >>>> text  in globals.hpp mentions only Linux which seems to be not fully
> >> correct):
> >>>>>
> >>>>> if (geteuid() != 0) { ... } in function prio_init().
> >>>>>
> >>>>> (looks like the check is not done for other platforms).
> >>>>>
> >>>>> However the check for root (e.g. on Linux)  hinders users to set a
> >>>> ****lower priority**** for a thread (== increase the "niceness" level)
> >>>>> when running as a non-root user  (there might be strange ways from
> >>>> outside the VM with calling scripts and renice but .... ).
> >>>>>
> >>>>>
> >>>>> In older JDKs (e.g. JDK8) there was a "workaround" to use for
> example
> >>>> ThreadPriorityPolicy=2 to avoid the root-check,
> >>>>> but this is not possible any more in recent JDKs (10/11) after the range
> >>>> check (0,1) has been introduced for the ThreadPriorityPolicy flag
> >>>>> (and probably the old workaround was not a good one anyway
> because
> >> it
> >>>> was undocumented).
> >>>>>
> >>>>> So do you think we could introduce another XX-flag  (
> >>>> AllowAggressiveThreadPriorityPolicyForAllUsers, or some better name)
> >>>>> that allows using the "aggressive" mode for non-root users ? Another
> >>>> option would be to add another mode 2 for ThreadPriorityPolicy
> >>>>> that documents the behavior (like mode 1 but without root-user
> check).
> >>>>>
> >>>>> If I get it right, even  setting  ***higher prios*** (lower niceness) is
> >>>> possible for non-root users on systems configured in an appropriate
> way
> >>>>> (using the CAP_SYS_NICE capability).
> >>>>>
> >>>>> But setting  lower prio / higher niceness is even possible for normal
> users
> >>>> NOW without special config, it is just disabled by the root-check
> >>>>> which is very bad.
> >>>>>
> >>>>> Best regards, Matthias
> >>>>>