linux-kernel - Re: posix-cpu-timers revamp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1206380079.21896.20.camel@bobble.smo.corp.google.com>
Date:	Mon, 24 Mar 2008 10:34:39 -0700
From:	Frank Mayhar <fmayhar@...gle.com>
To:	Roland McGrath <roland@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: posix-cpu-timers revamp

On Sat, 2008-03-22 at 14:58 -0700, Roland McGrath wrote:
> > I would really like to just ignore the 2-cpu scenario and just have two
> > versions, the UP version and the n-way SMP version.  It would make life,
> > and maintenance, simpler.
> Like I've said, it's only something to investigate for best performance.
> If the conditional code is encapsulated well, it will be simple to add
> another variant later and experiment with it.

Well, if it's acceptable, for a first cut (and the patch I'll submit),
I'll handle the UP and SMP cases, encapsulating them in sched.h in such
a way as to make it invisible (as much as is possible) to the rest of
the code.

> There are several important scenarios you did not test.
> Analysis of combinations of all these variables is needed.
> 1. Tests with a few threads, like as many threads as CPUs or only 2x as many.

I've actually done this, although I didn't find the numbers particularly
interesting.  I'll do it again and keep the numbers, though.

> 2. Tests with a process CPU timer set for a long expiration time.
>    i.e. a timer set, but that never goes off in your entire run.
>    (This is what a non-infinity RLIMIT_CPU limit does.)
>    With the old code, a long enough timer and a small enough number
>    of threads will never trigger a "rebalance".

I'll do this at some point.

> > I guess I could be wrong about this, but it appears to be what the code
> > is doing.  If my analysis is correct, I really don't need a new field,
> > since the old fields work just fine.
> 
> The analysis above is correct but your conclusion here is wrong.
> The current value of an itimer is a user feature, not just a piece
> of internal bookkeeping.

After looking at the code again, I now understand what you're talking
about.  You overloaded it_*_expires to support both the POSIX interval
timers and RLIMIT_CPU.  So the way I have things, setting one can stomp
the other.

> Your code causes any timer_settime or timer_delete call on a process
> CPU timer or any setrlimit call on RLIMIT_CPU to suddenly change the
> itimer setting just as if the user had made some setitimer call that
> was never made or intended.  That's wrong.

Right, because the original effect was to only set the it_*_expires on
each individual task struct, leaving the one in the signal struct alone.

Might it be cleaner to handle the RLIMIT_CPU stuff separately, rather
than rolling it into the itimer handling?
-- 
Frank Mayhar <fmayhar@...gle.com>
Google, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/