linux-kernel - Re: CFS review

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Aug 2007 19:41:19 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Mike Galbraith <efault@....de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: CFS review


* Roman Zippel <zippel@...ux-m68k.org> wrote:

> > i tried your fl.c and if sched_clock() is high-resolution it's scheduled 
> > _perfectly_ by CFS:
> > 
> >    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >   5906 mingo     20   0  1576  244  196 R 71.2  0.0   0:30.11 l
> >   5909 mingo     20   0  1844  344  260 S  9.6  0.0   0:04.02 lt
> >   5907 mingo     20   0  1844  508  424 S  9.5  0.0   0:04.01 lt
> >   5908 mingo     20   0  1844  344  260 S  9.5  0.0   0:04.02 lt
> > 
> > if sched_clock() is low-resolution then indeed the 'lt' tasks will 
> > "hide":
> > 
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >  2366 mingo     20   0  1576  248  196 R 99.9  0.0   0:07.95 loop_silent
> >     1 root      20   0  2132  636  548 S  0.0  0.0   0:04.64 init
> > 
> > but that's nothing new. CFS cannot conjure up time measurement 
> > methods that do not exist. If you have a low-res clock and if you 
> > create an app that syncs precisely to the tick of that clock via 
> > timers that run off that exact tick then there's nothing the 
> > scheduler can do about it. It is false to charachterise this as 
> > 'sleeper starvation' or 'rounding error' like you did. No amount of 
> > rounding logic can create a high-resolution clock out of thin air.
> 
> [...] I didn't say 'sleeper starvation' or 'rounding error', these are 
> your words and it's your perception of what I said.

Oh dear :-) It was indeed my preception that yesterday you said:

| A problem here is that this can be exploited, if a job is spread over 
|                        ^^^^^^^^^^^^^^^^^^^^^
| a few threads, they can get more time relativ to other tasks, e.g. in 
|                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| this example there are three tasks that run only for about 1ms every 
| 3ms, but they get far more time than should have gotten fairly:
|          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| 4544 roman     20   0  1796  520  432 S 32.1  0.4   0:21.08 lt
| 4545 roman     20   0  1796  344  256 R 32.1  0.3   0:21.07 lt
| 4546 roman     20   0  1796  344  256 R 31.7  0.3   0:21.07 lt
| 4547 roman     20   0  1532  272  216 R  3.3  0.2   0:01.94 l

 [ http://lkml.org/lkml/2007/7/31/668 ]

( the underlined portion, in other words, is called 'starvation'.)

And again today, i clearly perceived you to say:

| > in that case 'top' accounting symptoms similar to the above are not 
| > due to the scheduler starvation you suspected, but due the effect of 
| > a low-resolution scheduler clock and a tightly coupled 
| > timer/scheduler tick to it.
|
| Well, it magnifies the rounding problems in CFS.

 [ http://lkml.org/lkml/2007/8/1/153 ]

But you are right, that must be my perception alone, you couldnt 
possibly have said any of that =B-)

Or are you perhaps one of those who claims that saying something 
analogous to sleeper starvation does not equal to talking about 'sleeper 
starvation' and saying something about 'rounding problems in CFS' does 
in no way mean you were talking about rounding errors? :-)

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