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

Date:	Thu, 29 Mar 2007 17:34:31 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	davids@...master.com
CC:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: RSDL v0.31

David Schwartz wrote:
> Bill Davidsen wrote:
> 
> 
>>I agree for giving a process more than a fair share, but I don't think
>>"latency" is the best term for what you describe later. If you think of
>>latency as the time between a process unblocking and the time when it
>>gets CPU, that is a more traditional interpretation. I'm not really sure
>>latency and CPU-starved are compatible.
> 
> 
> For CPU-starvation, I think 'nice' is always going to be the fix. If you
> want a process to get more than its 'fair share' of the CPU, you have to ask
> for that. I think the scheduler should be fair by default.
> 
> However, cleverness in the scheduler with latency can make things better
> without being unfair to anyone. It's perfectly fair for a task that has been
> blocked for awhile to pre-empt a CPU-limited task when it unblocks.
> 
> What I'm arguing is that if your task is CPU-limited and the scheduler is
> fair, that's your fault -- nice it. If your task is suffering from poor
> latency, and it's using less than its fair share of the CPU (because it is
> not CPU-limited), that is something the scheduler can be smarter about.

Agreed. That's what I've been saying for years (since early 2.6 when we had
all those scheduler troubles and I started nicksched).

> Honestly, I have always been against aggressive pre-emption. I think as CPUs
> get faster and timeslices get shorter, it makes less and less sense. In many

I think scheduler timeslices actually shouldn't really be getting shorter.
While I found it is quite easy to get good interactivity with a pretty
dumb scheduler and tiny timeslices (at least until load ramps up enough
that the "off-time" for your critical processes builds up too much), I
think we want to aim for large timeslices. CPU caches are still getting
bigger, and I don't think misses are getting cheaper (especially if you
consider multi core). Also, the energy cost of a memory access is much
higher even if hardware or software is able to hide the latency.

-- 
SUSE Labs, Novell 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/