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]
Message-ID: <AANLkTimOx=cMr+cwzEc8z7puZDEpa_7aDOxCPSzotjBP@mail.gmail.com>
Date:	Thu, 28 Oct 2010 14:19:52 +0400
From:	Dragoslav Zaric <zaricdragoslav@...il.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Tickles scheduler

1.Currently processes in the system are in some kind of list I think
(double circular).
So what if we assign each process structure (task_struct) property for
priority (maybe already there)
and another property which is time how long should run. So instead
having ticker in system,
each process runs itself predetermined period of time based on
priority and probably few more
parameters that should be in algorithm.

2. Second, when adding process into list, we can have separate side
lists, created in advance (something
like slab), where each lists hold tasks of same priority. So when we
add new process to list, at same
time we add it to his priority list. Than scheduler goes trough these
lists, based on priority and each
tasks hold it's running time. So we have two points to ease algorithm,
lists with single priority and time inside
each process task_struct related to priority.

3. In this way time-granularity of the system is high and allows for
real-time behavior, because we do
not have outside time that we "cut" in the middle when interrupt
happens, we just interrupt current process and when
finished, scheduler continue to walk trough lists of processes that
run its own time.

regards

On Thu, Oct 28, 2010 at 2:26 AM, Christoph Lameter <cl@...ux.com> wrote:
> On Tue, 26 Oct 2010, Martin Nybo Andersen wrote:
>
>> On Tue, 26 Oct 2010, Dragoslav Zaric wrote:
>>
>> > [...]
>> >
>> > Is it at all possible to implement kernel without ticking, spin system
>> > by events and periods ?
>>
>> You can compile with CONFIG_NO_HZ=n if you want a ticking kernel.
>
> The kernel always ticks when a process is running CONFIG_NO_HZ does
> nothing for that.
>
>> > Maybe ticking is still best solution to have fast responding system ?
>
> I think we need a tickless kernel.... Yes....
>
>> My guesses are that it has already been benchmarked for speed, but you can
>> still test it yourself.
>> At least power usage/battery times is much better with a tickless kernel.
>
> Well yes CONFIG_NO_HZ really should say CONFIG_NO_HZ_IDLE. You have
> no ticks when a cpu is idle. Otherwise we are ticking...
>
>



-- 
Dragoslav Zaric

Professional Programmer
MSc Astrophysics
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ