linux-kernel - Re: [git pull] CPU isolation extensions

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: <20080207195130.GA27482@elte.hu>
Date:	Thu, 7 Feb 2008 20:51:30 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Max Krasnyansky <maxk@...lcomm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] CPU isolation extensions

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Wed, 6 Feb 2008, Max Krasnyansky wrote:
> >
> > Linus, please pull CPU isolation extensions from
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git 
> > for-linus
> 
> Have these been in -mm and widely discussed etc? I'd like to start 
> more carefully, and (a) have that controversial last patch not merged 
> initially and (b) make sure everybody is on the same page wrt this 
> all..

no, they have not been under nearly enough testing and review - these 
patches surfaced on lkml for the first time one week ago (!). I find the 
pull request totally premature, this stuff has not been discussed and 
agreed on _at all_. None of the people who maintain and have interest in 
this code and participated in the (short) one-week discussion were 
Cc:-ed to the pull request.

I think these patches also need a buy-in from Peter Zijlstra and Paul 
Jackson (or really good reasoning while any objections from them should 
be overriden) - all of whom deal with the code affected by these changes 
on a daily basis and have an interest in CPU isolation features.

Generally i think that cpusets is actually the feature and API that 
should be used (and extended) for CPU isolation - and we already 
extended it recently in the direction of CPU isolation. Most enterprise 
distros have cpusets enabled so it's in use. Also, cpusets has the 
appeal of being commonly used in the "big honking boxes" arena, so 
reusing the same concept for RT and virtualization stuff would be the 
natural approach. It already ties in to the scheduler domains code 
dynamically and is flexible and scalable. I resisted ad-hoc CPU 
isolation patches in -rt for that reason. Also, i'd not mind some 
test-coverage in sched.git as well.

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