[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-dev
Subject: RE: ThreadPriorityPolicy settings for non-root users
From: "Baesken, Matthias" <matthias.baesken () sap ! com>
Date: 2018-12-21 13:38:06
Message-ID: VI1PR02MB4384E0E570297748405EFA3393B80 () VI1PR02MB4384 ! eurprd02 ! prod ! outlook ! com
[Download RAW message or body]
> 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@oracle.com>
> Sent: Freitag, 21. Dezember 2018 13:47
> To: Lindenmaier, Goetz <goetz.lindenmaier@sap.com>; Baesken, Matthias
> <matthias.baesken@sap.com>; 'hotspot-dev@openjdk.java.net' <hotspot-
> dev@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@openjdk.java.net> On Behalf
> Of
> > > David Holmes
> > > Sent: Freitag, 21. Dezember 2018 11:56
> > > To: Baesken, Matthias <matthias.baesken@sap.com>; 'hotspot-
> > > dev@openjdk.java.net' <hotspot-dev@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@oracle.com>
> > > > > Sent: Donnerstag, 20. Dezember 2018 12:06
> > > > > To: Baesken, Matthias <matthias.baesken@sap.com>; 'hotspot-
> > > > > dev@openjdk.java.net' <hotspot-dev@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
> > > > > >
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic