[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170522093725.GF8509@dhcp22.suse.cz>
Date: Mon, 22 May 2017 11:37:25 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: Junaid Shahid <junaids@...gle.com>,
David Rientjes <rientjes@...gle.com>,
Alasdair Kergon <agk@...hat.com>,
Mike Snitzer <snitzer@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
andreslc@...gle.com, gthelen@...gle.com, vbabka@...e.cz,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params()
On Fri 19-05-17 19:43:23, Mikulas Patocka wrote:
>
>
> On Fri, 19 May 2017, Michal Hocko wrote:
>
> > On Thu 18-05-17 19:50:46, Junaid Shahid wrote:
> > > (Adding back the correct linux-mm email address and also adding linux-kernel.)
> > >
> > > On Thursday, May 18, 2017 01:41:33 PM David Rientjes wrote:
> > [...]
> > > > Let's ask Mikulas, who changed this from PF_MEMALLOC to __GFP_HIGH,
> > > > assuming there was a reason to do it in the first place in two different
> > > > ways.
> >
> > Hmm, the old PF_MEMALLOC used to have the following comment
> > /*
> > * Trying to avoid low memory issues when a device is
> > * suspended.
> > */
> >
> > I am not really sure what that means but __GFP_HIGH certainly have a
> > different semantic than PF_MEMALLOC. The later grants the full access to
> > the memory reserves while the prior on partial access. If this is _really_
> > needed then it deserves a comment explaining why.
> > --
> > Michal Hocko
> > SUSE Labs
>
> Sometimes, I/O to a device mapper device is blocked until the userspace
> daemon dmeventd does some action (for example, when dm-mirror leg fails,
> dmeventd needs to mark the leg as failed in the lvm metadata and then
> reload the device).
>
> The dmeventd daemon mlocks itself in memory so that it doesn't generate
> any I/O. But it must be able to call ioctls. __GFP_HIGH is there so that
> the ioctls issued by dmeventd have higher chance of succeeding if some I/O
> is blocked, waiting for dmeventd action. It reduces the possibility of
> low-memory-deadlock, though it doesn't eliminate it entirely.
So what happens if the memory reserves are depleted. Do we deadlock? Why
is OOM killer insufficient to allow the further progress?
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists