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: <20081030174925.36023f19jy3o832t@feanor.sssup.it>
Date:	Thu, 30 Oct 2008 17:49:25 +0100
From:	faggioli@...dalf.sssup.it
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	henrik@...tad.us, Ingo Molnar <mingo@...e.hu>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	fabio@...dalf.sssup.it, trimarchimichael@...oo.it
Subject: Re: Rearranging layout of code in the scheduler

Quoting Peter Zijlstra <peterz@...radead.org>:
>> Before I dive in, I should probably justify my motivations for writing
>> this email. I'm working away on implementing an EDF scheduler for real
>> time tasks in the kernel. This again leads to hacking at the existing
>> source as I'm not about to toss out the entire scheduler - just replace
>> (by some Kconfig switch) the RR/FIFO classes. As to why I'm looking at
>> EDF, I think the answer to that is a bit too long (and not appropriate
>> for this email anyway) so I'll leave that part out.
Well, I understand that, but it could be interesting... At least to me. :-)

> You and a few other folks.
Yes, here we are! :-)

We also have some code, but it still is highly experimental and we are  
deeply rearranging it.

> The most interesting part of EDF is not the
> actual scheduler itself (although there are fun issues with that as
> well), but extending the Priority Inheritance framework to deal with all
> the fun cases that come with EDF.
The main problem is that, especially to deal with SMP systems, we also  
need to investigate theoretical issues and find out what the best  
approach could be.

> Well, adding a sched_class, no need to replace anything besides that.
>
I'm not saying anything in possible sched.c and sched_{fair|rt}.c code  
rearranging, I also only wonder why replacing fixed priority RT  
scheduling with EDF.

I think they both could be in... Maybe we can discuss on where, I mean  
on which position, in the linked list of scheduling classes, to put  
each of them.

Regards,
Dario

Thanks for the Cc. Peter, I also added Fabio and Michael that, you  
know, are working to this thing. :-)

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
--
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