linux-kernel - Re: RSDL v0.31

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:	Sat, 17 Mar 2007 19:12:43 +0300
From:	Al Boldi <a1426z@...ab.com>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	ck@....kolivas.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: RSDL v0.31

Con Kolivas wrote:
> DEF_TIMESLICE is a value used for smp balancing and has no effect on quota
> so I doubt you mean that value. The quota you're describing of not
> resetting is something like the sleep average idea of current systems
> where you accumulate bonus points by sleeping when you would be running
> and redeem them later. This is exactly the system I'm avoiding using in
> rsdl as you'd have to decide just how much sleep time it could accumulate,
> and over how long it would run out, and so on. ie that's the interactivity
> estimator. This is the system that destroys any guarantee of cpu
> percentage, and ends up leading to periods of relative starvation, is open
> to tuning that can either be too short or too long depending on the values
> you chose and so on.

Ok, but I can clearly see an expiration happening for sleeping tasks, like X.  
It looks like it's climbing a ladder halfway, then it sleeps, and when it 
wakes up, it continues to complete the ladder to expiration.  Couldn't this 
sleep be taken into account, and reset the ladder position accordingly?

> > The thing is, latencies are currently dependent on the number of tasks
> > in the run-queue; i.e. more rq-tasks means higher latencies, yet fixed
> > timeslices according to nice.  Just switching this the other way around,
> > by fixing latencies according to nice, and adjusting the timeslices
> > depending on rq-load, may yield a much more scalable system.
>
> That is not really feasible to implement. How can you guarantee latencies
> when the system is overloaded? If you have 1000 tasks all trying to get
> scheduled in say 10ms you end up running for only 10 microseconds at a
> time. That will achieve the exact opposite whereby as the load increases
> the runtime gets shorter and shorter till cpu cache trashing and no real
> work occurs.

Most of the time we only run a small number of tasks.  And for the case of 
1000's of tasks, you could put in some lower threshold, that would trigger 
an increase of latency, if the timeslice became ridiculously small.


Thanks!

--
Al

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