Re: [PATCH 00/20] mm: Preemptibility -v4

Re: [PATCH 00/20] mm: Preemptibility -v4

[Mat]

Hi Peter,

I'm currently also testing your preemptibility patchset and have to
say that on top of 2.6.36-rc3 it really seems to make a positive
difference for me :)

since I'm only a regular (power)user utilizing linux-distributions for
my everyday work I can report only about that:

- the desktop stays very responsive even during copying, backing up
and transferring of large amounts of data (e.g. backing up 1 TB of
data via rsync between different filesystems); this includes the GUI
staying responsive, the mouse not lagging and apps opening up almost
instantaneously
- there is very little to no noticable lags or repetitions when
hearing webradio or audios during longer periods of time
- and much more


considering that 2.6.36 received several other improvements in this area
- http://lkml.org/lkml/2010/8/1/40, the patches from Wu Fengguang and
KOSAKI Motohiro
- concurrency managed workqueues
- and other performance improvements, especially VFS
may also add up to this

anyways: please consider adding this to next/mainline during the next
merge cycle

my linux-desktop didn't feel that reponsive for a long time ! ^^
if I recall correctly if felt comparably responsive when I used Con's
RSDL or SD scheduler - CFS and CFQ have made great progress in terms
of desktop usage, interactivity and delays

Regards and thanks to everyone involved in the continued improvements
in this area

Mat

[PATCH 00/20] mm: Preemptibility -v4

[Peter Zijlstra]

This patch-set makes part of the mm a lot more preemptible. It converts
i_mmap_lock and anon_vma->lock to mutexes and makes mmu_gather fully
preemptible.

The main motivation was making mm_take_all_locks() preemptible, since it
appears people are nesting hundreds of spinlocks there.

The side-effects are that can finally make mmu_gather preemptible,
something which lots of people have wanted to do for a long time.

It also gets us anon_vma refcounting, which seems to result in a nice
cleanup of the anon_vma lifetime rules wrt KSM and compaction.

This patch-set it build and boot-tested on x86_64 (a previous version was
also tested on Dave's Niagra2 machines, and I suppose s390 did too when
Martin provided the conversion patch for his arch).

There are no known architectures left unconverted, although some arch code
never did see a compiler (superh and ia64 come to mind, I'll try and 
update my toolchains next week).

Yanmin ran the last posting through the comprehensive Intel test farm
and didn't find any regressions.

( Not included in this posting are the 4 Sparc64 patches that implement
  gup_fast, those can be applied separately after this series gets 
  anywhere. )

Full series (including the Sparc64 gup_fast bits) also available in -git
form from (against Linus' tree as of about an hour ago):

  git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt

Do people feel its ready to get added to -next?

[PATCH 00/20] mm: Preemptibility -v4

[Peter Zijlstra]

This patch-set makes part of the mm a lot more preemptible. It converts
i_mmap_lock and anon_vma->lock to mutexes and makes mmu_gather fully
preemptible.

The main motivation was making mm_take_all_locks() preemptible, since it
appears people are nesting hundreds of spinlocks there.

The side-effects are that can finally make mmu_gather preemptible,
something which lots of people have wanted to do for a long time.

It also gets us anon_vma refcounting, which seems to result in a nice
cleanup of the anon_vma lifetime rules wrt KSM and compaction.

This patch-set it build and boot-tested on x86_64 (a previous version was
also tested on Dave's Niagra2 machines, and I suppose s390 did too when
Martin provided the conversion patch for his arch).

There are no known architectures left unconverted, although some arch code
never did see a compiler (superh and ia64 come to mind, I'll try and 
update my toolchains next week).

Yanmin ran the last posting through the comprehensive Intel test farm
and didn't find any regressions.

( Not included in this posting are the 4 Sparc64 patches that implement
  gup_fast, those can be applied separately after this series gets 
  anywhere. )

Full series (including the Sparc64 gup_fast bits) also available in -git
form from (against Linus' tree as of about an hour ago):

  git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt

Do people feel its ready to get added to -next?

Re: [PATCH 00/20] mm: Preemptibility -v4

[Peter Zijlstra]

Sorry folks, got Nick's old email in there (changed for this reply).

On Sat, 2010-08-28 at 16:16 +0200, Peter Zijlstra wrote:
> This patch-set makes part of the mm a lot more preemptible. It converts
> i_mmap_lock and anon_vma->lock to mutexes and makes mmu_gather fully
> preemptible.
> 
> The main motivation was making mm_take_all_locks() preemptible, since it
> appears people are nesting hundreds of spinlocks there.
> 
> The side-effects are that can finally make mmu_gather preemptible,
> something which lots of people have wanted to do for a long time.
> 
> It also gets us anon_vma refcounting, which seems to result in a nice
> cleanup of the anon_vma lifetime rules wrt KSM and compaction.
> 
> This patch-set it build and boot-tested on x86_64 (a previous version was
> also tested on Dave's Niagra2 machines, and I suppose s390 did too when
> Martin provided the conversion patch for his arch).
> 
> There are no known architectures left unconverted, although some arch code
> never did see a compiler (superh and ia64 come to mind, I'll try and 
> update my toolchains next week).
> 
> Yanmin ran the last posting through the comprehensive Intel test farm
> and didn't find any regressions.
> 
> ( Not included in this posting are the 4 Sparc64 patches that implement
>   gup_fast, those can be applied separately after this series gets 
>   anywhere. )
> 
> Full series (including the Sparc64 gup_fast bits) also available in -git
> form from (against Linus' tree as of about an hour ago):
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt
> 
> Do people feel its ready to get added to -next?

Re: [PATCH 00/20] mm: Preemptibility -v4

[David Miller]

I get 'as' segfaults during a "make -j128" of the kernel on sparc64
with these changes.

I'll try to track it down.

Re: [PATCH 00/20] mm: Preemptibility -v4

[Peter Zijlstra]

On Sat, 2010-08-28 at 15:28 -0700, David Miller wrote:
> I get 'as' segfaults during a "make -j128" of the kernel on sparc64
> with these changes.
> 
> I'll try to track it down.

Hrm, I let it run:

while :; do
 make O=foo/ clean;
 make O=foo/ randconfig;
 make O=foo/ -j48;
done

on my 24 cpu machine with this for like an hour, I'll let it run more
tomorrow to see if I can reproduce this.

Thanks for looking at this.

Re: [PATCH 00/20] mm: Preemptibility -v4

[Piotr Hosowicz]

On 28.08.2010 16:16, Peter Zijlstra wrote:

> Full series (including the Sparc64 gup_fast bits) also available in -git
> form from (against Linus' tree as of about an hour ago):

How come? I tried this:

aapi205:/usr/src/linus/tmp# git pull
Already up-to-date.

... and don't see an update. Maybe I don't do something right. If there 
is newer code I should receive it, am I correct? I use this link:

git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

-- 
Janusz Korwin-Mikke:
"Generalnie rzecz biorąc, ja jestem w jednej dziedzinie za
równouprawnieniem, a mianowicie: żeby w małżeństwie było
50% mężczyzn i 50% kobiet."
NP: Peter Green Splinter Group - Turn Your Love Away
NB: 2.6.36-rc2-next-20100827

Re: [PATCH 00/20] mm: Preemptibility -v4

[Peter Zijlstra]

On Sat, 2010-08-28 at 16:56 +0200, Piotr Hosowicz wrote:
> On 28.08.2010 16:16, Peter Zijlstra wrote:
> 
> > Full series (including the Sparc64 gup_fast bits) also available in -git
> > form from (against Linus' tree as of about an hour ago):
> 
> How come? I tried this:
> 
> aapi205:/usr/src/linus/tmp# git pull
> Already up-to-date.
> 
> ... and don't see an update. Maybe I don't do something right. If there 
> is newer code I should receive it, am I correct? I use this link:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

That's Linus' tree, the patches aren't in there quite yet, try:

  git remote add mmu_preempt git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
  git remote update
  git checkout mmu_preempt/mmu_preempt

or
  
  git checkout -b mmu_preempt origin/master
  git pull git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt

Re: [PATCH 00/20] mm: Preemptibility -v4

[Piotr Hosowicz]

On 28.08.2010 17:10, Peter Zijlstra wrote:
> On Sat, 2010-08-28 at 16:56 +0200, Piotr Hosowicz wrote:
>> On 28.08.2010 16:16, Peter Zijlstra wrote:
>>
>>> Full series (including the Sparc64 gup_fast bits) also available in -git
>>> form from (against Linus' tree as of about an hour ago):
>>
>> How come? I tried this:
>>
>> aapi205:/usr/src/linus/tmp# git pull
>> Already up-to-date.
>>
>> ... and don't see an update. Maybe I don't do something right. If there
>> is newer code I should receive it, am I correct? I use this link:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> That's Linus' tree, the patches aren't in there quite yet, try:
>
>    git remote add mmu_preempt git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
>    git remote update
>    git checkout mmu_preempt/mmu_preempt
>
> or
>
>    git checkout -b mmu_preempt origin/master
>    git pull git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt

Which is better? Thanks, I'll try.

Regards,

Piotr Hosowicz

-- 
Wzór Einsteina-Pitagorasa: E = mc2 = m(a2 + b2)
NP: Peter Green Splinter Group - Big Change Is Gonna Come
NB: 2.6.36-rc2-next-20100827

Re: [PATCH 00/20] mm: Preemptibility -v4

[Peter Zijlstra]

On Sat, 2010-08-28 at 17:17 +0200, Piotr Hosowicz wrote:
> >    git remote add mmu_preempt git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
> >    git remote update
> >    git checkout mmu_preempt/mmu_preempt
> >
> > or
> >
> >    git checkout -b mmu_preempt origin/master
> >    git pull git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt
> 
> Which is better? Thanks, I'll try.

Fully depends on how you manage your git tree, the first will keep
giving you the same tree while the second will try and merge my changes
into whatever you got from Linus' tree, which keeps moving fwd and might
thus start failing (at which point I'll have to either rebase or
backmerge Linus' changes).

Re: [PATCH 00/20] mm: Preemptibility -v4

[Piotr Hosowicz]

On 28.08.2010 17:23, Peter Zijlstra wrote:
> On Sat, 2010-08-28 at 17:17 +0200, Piotr Hosowicz wrote:
>>>     git remote add mmu_preempt git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
>>>     git remote update
>>>     git checkout mmu_preempt/mmu_preempt
>>>
>>> or
>>>
>>>     git checkout -b mmu_preempt origin/master
>>>     git pull git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt
>>
>> Which is better? Thanks, I'll try.
>
> Fully depends on how you manage your git tree, the first will keep
> giving you the same tree while the second will try and merge my changes
> into whatever you got from Linus' tree, which keeps moving fwd and might
> thus start failing (at which point I'll have to either rebase or
> backmerge Linus' changes).

I'll risk the second way. I almost do not manage the tree, I just copy 
my local copy to tmp dir, then git pull from Linus, if there are changes 
I build the kernel.

Regards,

Piotr Hosowicz

-- 
Z cyklu "Uroki demokracji", czyli pytania i odpowiedzi w teledurniejach:
- W którym kraju znajduje się Mount Everest?
- Hm, to nie Szkocja, prawda?
NP: Peter Green Splinter Group - I Can't Help Myself
NB: 2.6.36-rc2-next-20100827

Re: [PATCH 00/20] mm: Preemptibility -v4

[Piotr Hosowicz]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On 28.08.2010 17:23, Peter Zijlstra wrote:
> On Sat, 2010-08-28 at 17:17 +0200, Piotr Hosowicz wrote:
>>>     git remote add mmu_preempt git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
>>>     git remote update
>>>     git checkout mmu_preempt/mmu_preempt
>>>
>>> or
>>>
>>>     git checkout -b mmu_preempt origin/master
>>>     git pull git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git mmu_preempt
>>
>> Which is better? Thanks, I'll try.
>
> Fully depends on how you manage your git tree, the first will keep
> giving you the same tree while the second will try and merge my changes
> into whatever you got from Linus' tree, which keeps moving fwd and might
> thus start failing (at which point I'll have to either rebase or
> backmerge Linus' changes).

I chose the second path, kernel built OK, but then I had to build NVidia 
module and I started Xorg. I logged in and then the screen froze for a 
while, then Kde background went black and I had to hard reset the PC, 
bezcause couldn't switch to VT. I attach my Xorg log.

-- 
- E.T. phone home. - powiedział E.T.
- Dzwoni do centrali po wskazówki - domyślił się Stirlitz.
NP: Patrick O'Hearn - Chance
NB: 2.6.36-rc2-git5

[-- Attachment #2: Xorg.0.log.old --]
[-- Type: application/x-trash, Size: 12551 bytes --]

Re: [PATCH 00/20] mm: Preemptibility -v4

[Peter Zijlstra]

On Sun, 2010-08-29 at 14:46 +0200, Piotr Hosowicz wrote:
> build NVidia module 

Sorry, you're on your own.

Re: [PATCH 00/20] mm: Preemptibility -v4

[Piotr Hosowicz]

On 29.08.2010 15:37, Peter Zijlstra wrote:
> On Sun, 2010-08-29 at 14:46 +0200, Piotr Hosowicz wrote:
>> build NVidia module
>
> Sorry, you're on your own.
>

OK.

Regards,

Piotr Hosowicz

-- 
"Pirotechnicy zdetonowali na warszawskim Okęciu podejrzane ładunki,
znalezione przy porzuconym motocyklu. Wszystko wskazuje na to, że
był to fałszywy alarm". Z polskiego na nasze: "rozp* komuś motor".
NP: Patrick O'Hearn - Night Becomes Her
NB: 2.6.36-rc2-git5

Re: [PATCH 00/20] mm: Preemptibility -v4

[Piotr Hosowicz]

On 29.08.2010 14:46, Piotr Hosowicz wrote:
> On 28.08.2010 17:23, Peter Zijlstra wrote:
>> On Sat, 2010-08-28 at 17:17 +0200, Piotr Hosowicz wrote:
>>>> git remote add mmu_preempt
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
>>>>
>>>> git remote update
>>>> git checkout mmu_preempt/mmu_preempt
>>>>
>>>> or
>>>>
>>>> git checkout -b mmu_preempt origin/master
>>>> git pull
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
>>>> mmu_preempt
>>>
>>> Which is better? Thanks, I'll try.
>>
>> Fully depends on how you manage your git tree, the first will keep
>> giving you the same tree while the second will try and merge my changes
>> into whatever you got from Linus' tree, which keeps moving fwd and might
>> thus start failing (at which point I'll have to either rebase or
>> backmerge Linus' changes).
>
> I chose the second path, kernel built OK, but then I had to build NVidia
> module and I started Xorg. I logged in and then the screen froze for a
> while, then Kde background went black and I had to hard reset the PC,
> bezcause couldn't switch to VT. I attach my Xorg log.

Now I had done it the second way you described and everything seems to 
be working ok.

aapi205:~# uname -r
2.6.36-rc3-20100831-1507-pz+

If there will be any problems I'll write here.

Regards,

Piotr Hosowicz
-- 
Z cyklu "Uroki demokracji", czyli pytania i odpowiedzi w teledurniejach:
- Który aktor amerykański jest mężem Nicole Kidman?
- Forrest Gump.
NP: Peter Green Splinter Group - You'll Be Sorry Someday
NB: 2.6.36-rc3-20100831-1507-pz+

Re: [PATCH 00/20] mm: Preemptibility -v4

[Piotr Hosowicz]

On 31.08.2010 16:02, Piotr Hosowicz wrote:
> On 29.08.2010 14:46, Piotr Hosowicz wrote:
>> On 28.08.2010 17:23, Peter Zijlstra wrote:
>>> On Sat, 2010-08-28 at 17:17 +0200, Piotr Hosowicz wrote:
>>>>> git remote add mmu_preempt
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
>>>>>
>>>>>
>>>>> git remote update
>>>>> git checkout mmu_preempt/mmu_preempt
>>>>>
>>>>> or
>>>>>
>>>>> git checkout -b mmu_preempt origin/master
>>>>> git pull
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
>>>>>
>>>>> mmu_preempt
>>>>
>>>> Which is better? Thanks, I'll try.
>>>
>>> Fully depends on how you manage your git tree, the first will keep
>>> giving you the same tree while the second will try and merge my changes
>>> into whatever you got from Linus' tree, which keeps moving fwd and might
>>> thus start failing (at which point I'll have to either rebase or
>>> backmerge Linus' changes).
>>
>> I chose the second path, kernel built OK, but then I had to build NVidia
>> module and I started Xorg. I logged in and then the screen froze for a
>> while, then Kde background went black and I had to hard reset the PC,
>> bezcause couldn't switch to VT. I attach my Xorg log.
>
> Now I had done it the second way you described and everything seems to
> be working ok.

Sorry, I made a mistake - I had built it the first way.

Regards and sorry for the noise,

Piotr Hosowicz

-- 
Janusz Korwin-Mikke:
"Idiota z dyplomem to taki sam idiota,
jak przedtem - tylko z pretensjami."
NP: Peter Green Splinter Group - Tribal Dance
NB: 2.6.36-rc3-20100831-1507-pz+

Re: [PATCH 00/20] mm: Preemptibility -v4

[Piotr Hosowicz]

On 31.08.2010 16:02, Piotr Hosowicz wrote:
> On 29.08.2010 14:46, Piotr Hosowicz wrote:
>> On 28.08.2010 17:23, Peter Zijlstra wrote:
>>> On Sat, 2010-08-28 at 17:17 +0200, Piotr Hosowicz wrote:
>>>>> git remote add mmu_preempt
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
>>>>>
>>>>>
>>>>> git remote update
>>>>> git checkout mmu_preempt/mmu_preempt
>>>>>
>>>>> or
>>>>>
>>>>> git checkout -b mmu_preempt origin/master
>>>>> git pull
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
>>>>>
>>>>> mmu_preempt
>>>>
>>>> Which is better? Thanks, I'll try.
>>>
>>> Fully depends on how you manage your git tree, the first will keep
>>> giving you the same tree while the second will try and merge my changes
>>> into whatever you got from Linus' tree, which keeps moving fwd and might
>>> thus start failing (at which point I'll have to either rebase or
>>> backmerge Linus' changes).
>>
>> I chose the second path, kernel built OK, but then I had to build NVidia
>> module and I started Xorg. I logged in and then the screen froze for a
>> while, then Kde background went black and I had to hard reset the PC,
>> bezcause couldn't switch to VT. I attach my Xorg log.
>
> Now I had done it the second way you described and everything seems to
> be working ok.

Still works OK and I perceive that it is better, Peter.

Do you know when Linus will be back from Brazil?

Regards,

Piotr Hosowicz

-- 
Z cyklu "Uroki demokracji", czyli pytania i odpowiedzi w teledurniejach:
- Ile kół ma trójkołowiec?
- Dwa.
NP: Peter Green Splinter Group - Indians
NB: 2.6.36-rc3-20100831-1507-pz+

Re: [PATCH 00/20] mm: Preemptibility -v4

[Pekka Enberg]

Hi Peter,

On Sat, Aug 28, 2010 at 5:16 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> Yanmin ran the last posting through the comprehensive Intel test farm
> and didn't find any regressions.

Is there data somewhere that shows where this helps and how much?

                        Pekka

Re: [PATCH 00/20] mm: Preemptibility -v4

[Peter Zijlstra]

On Sat, 2010-08-28 at 18:19 +0300, Pekka Enberg wrote:
> Hi Peter,
> 
> On Sat, Aug 28, 2010 at 5:16 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > Yanmin ran the last posting through the comprehensive Intel test farm
> > and didn't find any regressions.
> 
> Is there data somewhere that shows where this helps and how much?

Yanmin didn't publish any data, but the main point of the series is to
not take hundreds of nested spinlocks. Not regressing is a fine state.

In theory the preemptible mmu could end up doing less TLB invalidates
for large unmaps and thus gain some performance there.

Re: [PATCH 00/20] mm: Preemptibility -v4

[Alex,Shi]

Peter:
We tested your tree base on 2.6.36-rc3 kernel. The testing covered on
Core2 2P, NHM-EP/WSM-EP machines, no clear performance regression found
on your patch compare to 36-rc3, and also no clear improvements on our
benchmarks. 

The benchmarks are listed in the following website, and plus some of
FFSB/FIO scenarios.  http://kernel-perf.sourceforge.net/ 

Regards! 
Alex 

> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Sat, Aug 28, 2010 at 10:16 PM
> Subject: [PATCH 00/20] mm: Preemptibility -v4
> To: Andrea Arcangeli <aarcange@redhat.com>, Avi Kivity
> <avi@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, Rik van Riel
> <riel@redhat.com>, Ingo Molnar <mingo@elte.hu>,
> akpm@linux-foundation.org, Linus Torvalds
> <torvalds@linux-foundation.org>
> Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Benjamin
> Herrenschmidt <benh@kernel.crashing.org>, David Miller
> <davem@davemloft.net>, Hugh Dickins <hugh.dickins@tiscali.co.uk>, Mel
> Gorman <mel@csn.ul.ie>, Nick Piggin <npiggin@suse.de>, Peter Zijlstra
> <a.p.zijlstra@chello.nl>, Paul McKenney <paulmck@linux.vnet.ibm.com>,
> Yanmin Zhang <yanmin_zhang@linux.intel.com>, Stephen Rothwell
> <sfr@canb.auug.org.au>
> 
> 
> This patch-set makes part of the mm a lot more preemptible. It converts
> i_mmap_lock and anon_vma->lock to mutexes and makes mmu_gather fully
> preemptible.
> 
> The main motivation was making mm_take_all_locks() preemptible, since it
> appears people are nesting hundreds of spinlocks there.
> 
> The side-effects are that can finally make mmu_gather preemptible,
> something which lots of people have wanted to do for a long time.
> 
> It also gets us anon_vma refcounting, which seems to result in a nice
> cleanup of the anon_vma lifetime rules wrt KSM and compaction.
> 
> This patch-set it build and boot-tested on x86_64 (a previous version was
> also tested on Dave's Niagra2 machines, and I suppose s390 did too when
> Martin provided the conversion patch for his arch).
> 
> There are no known architectures left unconverted, although some arch code
> never did see a compiler (superh and ia64 come to mind, I'll try and
> update my toolchains next week).
> 
> Yanmin ran the last posting through the comprehensive Intel test farm
> and didn't find any regressions.
> 
> ( Not included in this posting are the 4 Sparc64 patches that implement
>  gup_fast, those can be applied separately after this series gets
>  anywhere. )
> 
> Full series (including the Sparc64 gup_fast bits) also available in -git
> form from (against Linus' tree as of about an hour ago):
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-mmu_preempt.git
> mmu_preempt
> 
> Do people feel its ready to get added to -next?
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/20] mm: Preemptibility -v4

[Peter Zijlstra]

On Tue, 2010-09-14 at 13:36 +0800, Alex,Shi wrote:
> Peter:
> We tested your tree base on 2.6.36-rc3 kernel. The testing covered on
> Core2 2P, NHM-EP/WSM-EP machines, no clear performance regression found
> on your patch compare to 36-rc3, and also no clear improvements on our
> benchmarks. 
> 
> The benchmarks are listed in the following website, and plus some of
> FFSB/FIO scenarios.  http://kernel-perf.sourceforge.net/ 

Thanks, much appreciated!!

Hopefully we'll get sparc64 fixed up soon and can talk about merging
this.