linux-kernel - Re: Stolen and degraded time and schedulers

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, 14 Mar 2007 02:20:32 -0600
From:	Zan Lynx <zlynx@....org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Stolen and degraded time and schedulers

On Tue, 2007-03-13 at 23:52 -0700, Jeremy Fitzhardinge wrote:
> Yep.  But the tsc is just an example of a clocksource, and doesn't have
> any real bearing on what I'm saying.
[cut/snip/slash]
> Well, it doesn't need to be a constant clock if its modelling a changing
> rate.  And it doesn't need to be an exact model; it just needs to be
> better than the current situation.

It's 2 AM so I don't know if I'm making sense, but I had an idea for the
sort of clock I think you're looking for.

Couldn't one of the CPU performance counters do this?  I think you can
set one to count cycles and trigger every 100,000, or 10,000 or 1,000,
or whatever.  Then when you get that interrupt hit the context switch.

Then every time slice would be in cycles and not wall-clock, which is
what I think you wanted.
-- 
Zan Lynx <zlynx@....org>

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)