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?
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?
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
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
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
Hi Peter,
On Sat, Aug 28, 2010 at 5:16 PM, Peter Zijlstra <[email protected]> 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
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).
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 <[email protected]> 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.
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
I get 'as' segfaults during a "make -j128" of the kernel on sparc64
with these changes.
I'll try to track it down.
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.
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
On Sun, 2010-08-29 at 14:46 +0200, Piotr Hosowicz wrote:
> build NVidia module
Sorry, you're on your own.
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
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+
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+