From: Brian Foster <bfoster@redhat.com> To: Michal Hocko <mhocko@kernel.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, Xiong Zhou <xzhou@redhat.com>, Christoph Hellwig <hch@infradead.org>, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: mm allocation failure and hang when running xfstests generic/269 on xfs Date: Thu, 2 Mar 2017 09:23:15 -0500 [thread overview] Message-ID: <20170302142315.GE3213@bfoster.bfoster> (raw) In-Reply-To: <20170302135001.GI1404@dhcp22.suse.cz> On Thu, Mar 02, 2017 at 02:50:01PM +0100, Michal Hocko wrote: > On Thu 02-03-17 08:41:58, Brian Foster wrote: > > On Thu, Mar 02, 2017 at 02:27:55PM +0100, Michal Hocko wrote: > [...] > > > I see your argument about being in sync with other kmem helpers but > > > those are bit different because regular page/slab allocators allow never > > > fail semantic (even though this is mostly ignored by those helpers which > > > implement their own retries but that is a different topic). > > > > > > > ... but what I'm trying to understand here is whether this failure > > scenario is specific to vmalloc() or whether the other kmem_*() > > functions are susceptible to the same problem. For example, suppose we > > replaced this kmem_zalloc_greedy() call with a kmem_zalloc(PAGE_SIZE, > > KM_SLEEP) call. Could we hit the same problem if the process is killed? > > Well, kmem_zalloc uses kmalloc which can also fail when we are out of > memory but in that case we can expect the OOM killer releasing some > memory which would allow us to make a forward progress on the next > retry. So essentially retrying around kmalloc is much more safe in this > regard. Failing vmalloc might be permanent because there is no vmalloc > space to allocate from or much more likely due to already mentioned > patch. So vmalloc is different, really. Right.. that's why I'm asking. So it's technically possible but highly unlikely due to the different failure characteristics. That seems reasonable to me, then. To be clear, do we understand what causes the vzalloc() failure to be effectively permanent in this specific reproducer? I know you mention above that we could be out of vmalloc space, but that doesn't clarify whether there are other potential failure paths or then what this has to do with the fact that the process was killed. Does the pending signal cause the subsequent failures or are you saying that there is some other root cause of the failure, this process would effectively be spinning here anyways, and we're just noticing it because it's trying to exit? Brian > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Brian Foster <bfoster@redhat.com> To: Michal Hocko <mhocko@kernel.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>, Xiong Zhou <xzhou@redhat.com>, Christoph Hellwig <hch@infradead.org>, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: mm allocation failure and hang when running xfstests generic/269 on xfs Date: Thu, 2 Mar 2017 09:23:15 -0500 [thread overview] Message-ID: <20170302142315.GE3213@bfoster.bfoster> (raw) In-Reply-To: <20170302135001.GI1404@dhcp22.suse.cz> On Thu, Mar 02, 2017 at 02:50:01PM +0100, Michal Hocko wrote: > On Thu 02-03-17 08:41:58, Brian Foster wrote: > > On Thu, Mar 02, 2017 at 02:27:55PM +0100, Michal Hocko wrote: > [...] > > > I see your argument about being in sync with other kmem helpers but > > > those are bit different because regular page/slab allocators allow never > > > fail semantic (even though this is mostly ignored by those helpers which > > > implement their own retries but that is a different topic). > > > > > > > ... but what I'm trying to understand here is whether this failure > > scenario is specific to vmalloc() or whether the other kmem_*() > > functions are susceptible to the same problem. For example, suppose we > > replaced this kmem_zalloc_greedy() call with a kmem_zalloc(PAGE_SIZE, > > KM_SLEEP) call. Could we hit the same problem if the process is killed? > > Well, kmem_zalloc uses kmalloc which can also fail when we are out of > memory but in that case we can expect the OOM killer releasing some > memory which would allow us to make a forward progress on the next > retry. So essentially retrying around kmalloc is much more safe in this > regard. Failing vmalloc might be permanent because there is no vmalloc > space to allocate from or much more likely due to already mentioned > patch. So vmalloc is different, really. Right.. that's why I'm asking. So it's technically possible but highly unlikely due to the different failure characteristics. That seems reasonable to me, then. To be clear, do we understand what causes the vzalloc() failure to be effectively permanent in this specific reproducer? I know you mention above that we could be out of vmalloc space, but that doesn't clarify whether there are other potential failure paths or then what this has to do with the fact that the process was killed. Does the pending signal cause the subsequent failures or are you saying that there is some other root cause of the failure, this process would effectively be spinning here anyways, and we're just noticing it because it's trying to exit? Brian > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-03-02 14:23 UTC|newest] Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-01 4:46 mm allocation failure and hang when running xfstests generic/269 on xfs Xiong Zhou 2017-03-01 4:46 ` Xiong Zhou 2017-03-02 0:37 ` Christoph Hellwig 2017-03-02 0:37 ` Christoph Hellwig 2017-03-02 5:19 ` Xiong Zhou 2017-03-02 5:19 ` Xiong Zhou 2017-03-02 6:41 ` Bob Liu 2017-03-02 6:41 ` Bob Liu 2017-03-02 6:41 ` Bob Liu 2017-03-02 6:41 ` Bob Liu 2017-03-02 6:47 ` Anshuman Khandual 2017-03-02 6:47 ` Anshuman Khandual 2017-03-02 8:42 ` Michal Hocko 2017-03-02 8:42 ` Michal Hocko 2017-03-02 9:23 ` Xiong Zhou 2017-03-02 9:23 ` Xiong Zhou 2017-03-02 10:04 ` Tetsuo Handa 2017-03-02 10:04 ` Tetsuo Handa 2017-03-02 10:35 ` Michal Hocko 2017-03-02 10:35 ` Michal Hocko 2017-03-02 10:35 ` Michal Hocko 2017-03-02 10:53 ` mm allocation failure and hang when running xfstests generic/269on xfs Tetsuo Handa 2017-03-02 10:53 ` Tetsuo Handa 2017-03-02 12:24 ` mm allocation failure and hang when running xfstests generic/269 on xfs Brian Foster 2017-03-02 12:24 ` Brian Foster 2017-03-02 12:49 ` Michal Hocko 2017-03-02 12:49 ` Michal Hocko 2017-03-02 13:00 ` Brian Foster 2017-03-02 13:00 ` Brian Foster 2017-03-02 13:07 ` Tetsuo Handa 2017-03-02 13:07 ` Tetsuo Handa 2017-03-02 13:27 ` Michal Hocko 2017-03-02 13:27 ` Michal Hocko 2017-03-02 13:41 ` Brian Foster 2017-03-02 13:41 ` Brian Foster 2017-03-02 13:50 ` Michal Hocko 2017-03-02 13:50 ` Michal Hocko 2017-03-02 14:23 ` Brian Foster [this message] 2017-03-02 14:23 ` Brian Foster 2017-03-02 14:34 ` Michal Hocko 2017-03-02 14:34 ` Michal Hocko 2017-03-02 14:51 ` Brian Foster 2017-03-02 14:51 ` Brian Foster 2017-03-02 15:14 ` Michal Hocko 2017-03-02 15:14 ` Michal Hocko 2017-03-02 15:30 ` Brian Foster 2017-03-02 15:30 ` Brian Foster 2017-03-02 15:45 ` [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail Michal Hocko 2017-03-02 15:45 ` Michal Hocko 2017-03-02 15:45 ` Michal Hocko 2017-03-02 15:45 ` Michal Hocko 2017-03-02 15:45 ` [PATCH 2/2] xfs: back off from kmem_zalloc_greedy if the task is killed Michal Hocko 2017-03-02 15:45 ` Michal Hocko 2017-03-02 15:45 ` Michal Hocko 2017-03-02 15:45 ` Michal Hocko 2017-03-02 15:49 ` Christoph Hellwig 2017-03-02 15:49 ` Christoph Hellwig 2017-03-02 15:59 ` Brian Foster 2017-03-02 15:59 ` Brian Foster 2017-03-02 15:49 ` [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail Christoph Hellwig 2017-03-02 15:49 ` Christoph Hellwig 2017-03-02 15:59 ` Brian Foster 2017-03-02 15:59 ` Brian Foster 2017-03-02 16:16 ` Michal Hocko 2017-03-02 16:16 ` Michal Hocko 2017-03-02 16:44 ` Darrick J. Wong 2017-03-02 16:44 ` Darrick J. Wong 2017-03-03 22:54 ` Dave Chinner 2017-03-03 22:54 ` Dave Chinner 2017-03-03 23:19 ` Darrick J. Wong 2017-03-03 23:19 ` Darrick J. Wong 2017-03-04 4:48 ` Dave Chinner 2017-03-04 4:48 ` Dave Chinner 2017-03-06 13:21 ` Michal Hocko 2017-03-06 13:21 ` Michal Hocko 2017-03-02 15:47 ` mm allocation failure and hang when running xfstests generic/269 on xfs Michal Hocko 2017-03-02 15:47 ` Michal Hocko 2017-03-02 15:47 ` Christoph Hellwig 2017-03-02 15:47 ` Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170302142315.GE3213@bfoster.bfoster \ --to=bfoster@redhat.com \ --cc=hch@infradead.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-xfs@vger.kernel.org \ --cc=mhocko@kernel.org \ --cc=penguin-kernel@I-love.SAKURA.ne.jp \ --cc=xzhou@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.