Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1367210 > unrolled thread

Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Peter Zijlstra <peterz@infradead.org> - 2016-03-30 15:40 +0200
    Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Michal Hocko <mhocko@kernel.org> - 2016-03-31 11:00 +0200
      Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Ingo Molnar <mingo@kernel.org> - 2016-03-31 11:40 +0200
        Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Michal Hocko <mhocko@kernel.org> - 2016-03-31 13:00 +0200
        Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Andrew Morton <akpm@linux-foundation.org> - 2016-03-31 19:10 +0200
          Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Ingo Molnar <mingo@kernel.org> - 2016-04-01 08:40 +0200
            Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Michal Hocko <mhocko@kernel.org> - 2016-04-01 11:30 +0200
              Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Ingo Molnar <mingo@kernel.org> - 2016-04-01 12:00 +0200
                Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Michal Hocko <mhocko@kernel.org> - 2016-04-01 13:00 +0200
          Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Michal Hocko <mhocko@kernel.org> - 2016-04-01 09:30 +0200
            Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore Andrew Morton <akpm@linux-foundation.org> - 2016-04-01 11:20 +0200

#1367210 — Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore

On Mon, Feb 29, 2016 at 01:58:14PM +0100, Michal Hocko wrote:
> I have tested on x86 with OOM situations with high mmap_sem contention
> (basically many parallel page faults racing with many parallel mmap/munmap
> tight loops) so the waiters for the write locks are routinely interrupted
> by SIGKILL.

Aside from the one niggle (as per the other email) they look good to me
and I would take them through the tip/locking tree.

Thanks!

[toc] | [next] | [standalone]

#1368020

On Wed 30-03-16 15:32:17, Peter Zijlstra wrote:
> On Mon, Feb 29, 2016 at 01:58:14PM +0100, Michal Hocko wrote:
> > I have tested on x86 with OOM situations with high mmap_sem contention
> > (basically many parallel page faults racing with many parallel mmap/munmap
> > tight loops) so the waiters for the write locks are routinely interrupted
> > by SIGKILL.
> 
> Aside from the one niggle (as per the other email) they look good to me
> and I would take them through the tip/locking tree.

Thanks for the review! I understand that tip/locking would be the most
appropriate place but I am wondering whether this causes some issues
with the follow up patches which use this new API and which I expect to
go via Andrew's tree.

That being said I do not care much but then we have a potential
dependency between mmotm and tip/locking.

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1368098

* Michal Hocko <mhocko@kernel.org> wrote:

> On Wed 30-03-16 15:32:17, Peter Zijlstra wrote:
> > On Mon, Feb 29, 2016 at 01:58:14PM +0100, Michal Hocko wrote:
> > > I have tested on x86 with OOM situations with high mmap_sem contention
> > > (basically many parallel page faults racing with many parallel mmap/munmap
> > > tight loops) so the waiters for the write locks are routinely interrupted
> > > by SIGKILL.
> > 
> > Aside from the one niggle (as per the other email) they look good to me
> > and I would take them through the tip/locking tree.
> 
> Thanks for the review! I understand that tip/locking would be the most 
> appropriate place [...]

Yes.

> [...] but I am wondering whether this causes some issues with the follow up 
> patches which use this new API and which I expect to go via Andrew's tree.

So AFAIK Andrew's tree is based on top of linux-next, so once it goes into 
tip:locking/core, -mm can pick it up as well 1-2 days later.

Please send the changes in isolation, for merge into the locking tree.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1368172

On Thu 31-03-16 11:20:05, Ingo Molnar wrote:
> 
> * Michal Hocko <mhocko@kernel.org> wrote:
> 
> > On Wed 30-03-16 15:32:17, Peter Zijlstra wrote:
> > > On Mon, Feb 29, 2016 at 01:58:14PM +0100, Michal Hocko wrote:
> > > > I have tested on x86 with OOM situations with high mmap_sem contention
> > > > (basically many parallel page faults racing with many parallel mmap/munmap
> > > > tight loops) so the waiters for the write locks are routinely interrupted
> > > > by SIGKILL.
> > > 
> > > Aside from the one niggle (as per the other email) they look good to me
> > > and I would take them through the tip/locking tree.
> > 
> > Thanks for the review! I understand that tip/locking would be the most 
> > appropriate place [...]
> 
> Yes.
> 
> > [...] but I am wondering whether this causes some issues with the follow up 
> > patches which use this new API and which I expect to go via Andrew's tree.
> 
> So AFAIK Andrew's tree is based on top of linux-next, so once it goes into 
> tip:locking/core, -mm can pick it up as well 1-2 days later.

OK. Andrew, just make sure you send the follow up changes to Linus after
tip/locking is merged.

> Please send the changes in isolation, for merge into the locking tree.

Yes, that's what I plan to do in few days.

Thanks!
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1368458

On Thu, 31 Mar 2016 11:20:05 +0200 Ingo Molnar <mingo@kernel.org> wrote:

> So AFAIK Andrew's tree is based on top of linux-next

Not really true any more - I only base -mm patches on linux-next
patches when they must be based that way due to some known dependency.

I can certainly handle MM patches which are based on linux-next.  Such
an arrangement is going to make life awkward for Michal's
auto-maintained git tree of the -mm MM patches
(git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git).

Maybe I could merge down_write_killable into -mm's main MM section then
knock it out of my copy of linux-next, so everything is seamless for
mm.git.  I've done that before.

But it's all a bit of a pain - it would be simpler to keep
down_write_killable in the same tree as the patches which depend on it.


Michal, how about this?

mm.git currently takes the patches between

#NEXT_PATCHES_START mm
...
#NEXT_PATCHES_END


Can you change it to also take the patches between

#NEXT_PATCHES_START mm-post-next
...
#NEXT_PATCHES_END

?

That way I can do


#NEXT_PATCHES_START mm
...
#NEXT_PATCHES_END
...
linux-next.patch
revert-down_write_killable.patch
...
#NEXT_PATCHES_START mm-post-next
down_write_killlable.patch
...
#NEXT_PATCHES_END

then everything you have should apply and run OK.

[toc] | [prev] | [next] | [standalone]

#1369019

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu, 31 Mar 2016 11:20:05 +0200 Ingo Molnar <mingo@kernel.org> wrote:
> 
> > So AFAIK Andrew's tree is based on top of linux-next
> 
> Not really true any more - I only base -mm patches on linux-next
> patches when they must be based that way due to some known dependency.
> 
> I can certainly handle MM patches which are based on linux-next.  Such
> an arrangement is going to make life awkward for Michal's
> auto-maintained git tree of the -mm MM patches
> (git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git).
> 
> Maybe I could merge down_write_killable into -mm's main MM section then
> knock it out of my copy of linux-next, so everything is seamless for
> mm.git.  I've done that before.
> 
> But it's all a bit of a pain - it would be simpler to keep
> down_write_killable in the same tree as the patches which depend on it.

I can help on the Git level: I can do tip:locking/rwsem tree with only these 
changes, with stable sha1's, on which the remaining work can be based. The
locking tree typically goes in early during the merge window, so there's no
real dependencies.

On the source code level this series is changing the existing locking code too,
it doesn't just add a new orthogonal method or so, so I'd really like to have
it in the locking tree.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1369129

On Fri 01-04-16 08:33:48, Ingo Molnar wrote:
[...]
> I can help on the Git level: I can do tip:locking/rwsem tree with only these 
> changes, with stable sha1's, on which the remaining work can be based. The
> locking tree typically goes in early during the merge window, so there's no
> real dependencies.

OK, I will wait for this series to apear in tip:locking/rwsem and then
post the follow up patches to Andrew. If you can base this branch on 4.5
that would be ideal for mmotm git tree workflow but I can work that
around should there be a complication.

Thanks!
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1369140

* Michal Hocko <mhocko@kernel.org> wrote:

> On Fri 01-04-16 08:33:48, Ingo Molnar wrote:
> [...]
> > I can help on the Git level: I can do tip:locking/rwsem tree with only these 
> > changes, with stable sha1's, on which the remaining work can be based. The
> > locking tree typically goes in early during the merge window, so there's no
> > real dependencies.
> 
> OK, I will wait for this series to apear in tip:locking/rwsem and then post the 
> follow up patches to Andrew. [...]

Well, 'this series' was posted a month ago, and patch #3 had a discussion and some 
corrections to it - so please re-send with a v4.6-rc1 base. (v4.5 is fine too if 
you double check that v4.6-rc1 merges cleanly with it.)

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1369204

On Fri 01-04-16 11:50:00, Ingo Molnar wrote:
> 
> * Michal Hocko <mhocko@kernel.org> wrote:
> 
> > On Fri 01-04-16 08:33:48, Ingo Molnar wrote:
> > [...]
> > > I can help on the Git level: I can do tip:locking/rwsem tree with only these 
> > > changes, with stable sha1's, on which the remaining work can be based. The
> > > locking tree typically goes in early during the merge window, so there's no
> > > real dependencies.
> > 
> > OK, I will wait for this series to apear in tip:locking/rwsem and then post the 
> > follow up patches to Andrew. [...]
> 
> Well, 'this series' was posted a month ago, and patch #3 had a discussion and some 
> corrections to it - so please re-send with a v4.6-rc1 base. (v4.5 is fine too if 
> you double check that v4.6-rc1 merges cleanly with it.)

Sure will do.

Thanks!
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1369061

On Thu 31-03-16 10:03:31, Andrew Morton wrote:
> On Thu, 31 Mar 2016 11:20:05 +0200 Ingo Molnar <mingo@kernel.org> wrote:
> 
> > So AFAIK Andrew's tree is based on top of linux-next
> 
> Not really true any more - I only base -mm patches on linux-next
> patches when they must be based that way due to some known dependency.
> 
> I can certainly handle MM patches which are based on linux-next.  Such
> an arrangement is going to make life awkward for Michal's
> auto-maintained git tree of the -mm MM patches
> (git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git).

Don't worry about my mmotm git tree. I will either cherry-pick these
patches from the tip or if Ingo can base them on 4.5 then I can pull
from his branch.

I was more worried about dependencies when you send your patch bomb to
Linus because then it is an additional burden on you to watch for tip
merge before you send yours.

Thanks!
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1369122

On Fri, 1 Apr 2016 09:26:54 +0200 Michal Hocko <mhocko@kernel.org> wrote:

> I was more worried about dependencies when you send your patch bomb to
> Linus because then it is an additional burden on you to watch for tip
> merge before you send yours.

That happens pretty often.  I haven't screwed it up yet ;)

Usually stuff just won't compile, but I always have little notes-to-self
in the series file reminding me to check stuff.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web