linux-kernel - Re: Commit 1e5a74059f9 broke utime measurement of ptraced() processes

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1324973051.5217.112.camel@marge.simson.net>
Date:	Tue, 27 Dec 2011 09:04:11 +0100
From:	Mike Galbraith <efault@....de>
To:	Артем Анисимов 
	<aanisimov@...ox.ru>
Cc:	linux-kernel@...r.kernel.org, a.p.zijlstra@...llo.nl, mingo@...e.hu
Subject: Re: Commit 1e5a74059f9 broke utime measurement of ptraced()
 processes

On Tue, 2011-12-27 at 11:30 +0300, Артем Анисимов wrote:
> On Saturday 24 December 2011 10:42:46, Mike Galbraith wrote :
> 
> > 
> > >   Also I'd like to know if there is a way to get reliable utime
> > >   measurements in recent kernels.
> > 
> > If wakeup preemption is undesirable, you could run SCHED_BATCH.
> 
> > CPU utilization shifts with wakeup preemption, so there will be visible
> > effect when you change wakeup preemption in any way.
> 
>   Thanks, SCHED_BATCH does solve my problem. I'd like to modify the man page 
> times (2) so that it includes a warning on utime of processes that wake each 
> other. Do you find the following note correct?

Yeah, guess so.  I'd leave out the "hand a few wakeup expense...",
that's just a small side effect of not wasting cycles doing very nearly
back to back clock updates for no good reason.  The important thing to
note is that utilization is affected by sleep/wakeup patterns.

> ----- to be added to times (2) -----
>   On Linux, the user time of a process depends on pattern of wakeups of the 
> process. The scheduler is permitted to cut waker's CPU usage and hand a few 
> wakeup expense cycles to the wakee that preempted. As a consequence, if two 
> processes A and B wake each other frequently (e.g., they communicate via 
> pipes, or by sending signals) then only the collective user time of A and B is 
> well defined; individual user times of A and B can be arbitrarily 
> redistributed between them. If this behaviour is undesirable then both 
> processes need to use the SCHED_BATCH scheduler class, see 
> sched_setscheduler(2).
> ----- to be added to times (2) -----


--
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/