All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junxiao Bi <junxiao.bi@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xuejiufei@huawei.com, Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	"ocfs2-devel@oss.oracle.com" <ocfs2-devel@oss.oracle.com>
Subject: [Ocfs2-devel] [PATCH] fs/super.c: do not shrink fs slab during direct memory reclaim
Date: Wed, 03 Sep 2014 12:21:24 +0800	[thread overview]
Message-ID: <54069744.7050509@oracle.com> (raw)
In-Reply-To: <20140903031023.GC20473@dastard>

On 09/03/2014 11:10 AM, Dave Chinner wrote:
> On Wed, Sep 03, 2014 at 09:38:31AM +0800, Junxiao Bi wrote:
>> Hi Jiufei,
>>
>> On 09/02/2014 05:03 PM, Xue jiufei wrote:
>>> Hi, Dave
>>> On 2014/9/2 7:51, Dave Chinner wrote:
>>>> On Fri, Aug 29, 2014 at 05:57:22PM +0800, Xue jiufei wrote:
>>>>> The patch trys to solve one deadlock problem caused by cluster
>>>>> fs, like ocfs2. And the problem may happen at least in the below
>>>>> situations:
>>>>> 1)Receiving a connect message from other nodes, node queues a
>>>>> work_struct o2net_listen_work.
>>>>> 2)o2net_wq processes this work and calls sock_alloc() to allocate
>>>>> memory for a new socket.
>>>>> 3)It would do direct memory reclaim when available memory is not
>>>>> enough and trigger the inode cleanup. That inode being cleaned up
>>>>> is happened to be ocfs2 inode, so call evict()->ocfs2_evict_inode()
>>>>> ->ocfs2_drop_lock()->dlmunlock()->o2net_send_message_vec(),
>>>>> and wait for the unlock response from master.
>>>>> 4)tcp layer received the response, call o2net_data_ready() and
>>>>> queue sc_rx_work, waiting o2net_wq to process this work.
>>>>> 5)o2net_wq is a single thread workqueue, it process the work one by
>>>>> one. Right now it is still doing o2net_listen_work and cannot handle
>>>>> sc_rx_work. so we deadlock.
>>>>>
>>>>> It is impossible to set GFP_NOFS for memory allocation in sock_alloc().
>>>>> So we use PF_FSTRANS to avoid the task reentering filesystem when
>>>>> available memory is not enough.
>>>>>
>>>>> Signed-off-by: joyce.xue <xuejiufei@huawei.com>
>>>>
>>>> For the second time: use memalloc_noio_save/memalloc_noio_restore.
>>>> And please put a great big comment in the code explaining why you
>>>> need to do this special thing with memory reclaim flags.
>>>>
>>>> Cheers,
>>>>
>>>> Dave.
>>>>
>>> Thanks for your reply. But I am afraid that memalloc_noio_save/
>>> memalloc_noio_restore can not solve my problem. __GFP_IO is cleared
>>> if PF_MEMALLOC_NOIO is set and can avoid doing IO in direct memory
>>> reclaim. However, __GFP_FS is still set that can not avoid pruning
>>> dcache and icache in memory allocation, resulting in the deadlock I
>>> described.
>>
>> You can use PF_MEMALLOC_NOIO to replace PF_FSTRANS, set this flag in
>> ocfs2 and check it in sb shrinker.
> 
> No changes to the superblock shrinker, please. The flag should
> modify the gfp_mask in the struct shrink_control passed to the
> shrinker, just like the noio flag is used in the rest of the mm
> code.
__GFP_FS seemed imply __GFP_IO, can superblock shrinker check
!(sc->gfp_mask & __GFP_IO) and stop?

Thanks,
Junxiao.
> 
> Cheers,
> 
> Dave.
> 

WARNING: multiple messages have this Message-ID (diff)
From: Junxiao Bi <junxiao.bi@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xuejiufei@huawei.com, Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	"ocfs2-devel@oss.oracle.com" <ocfs2-devel@oss.oracle.com>
Subject: Re: [PATCH] fs/super.c: do not shrink fs slab during direct memory reclaim
Date: Wed, 03 Sep 2014 12:21:24 +0800	[thread overview]
Message-ID: <54069744.7050509@oracle.com> (raw)
In-Reply-To: <20140903031023.GC20473@dastard>

On 09/03/2014 11:10 AM, Dave Chinner wrote:
> On Wed, Sep 03, 2014 at 09:38:31AM +0800, Junxiao Bi wrote:
>> Hi Jiufei,
>>
>> On 09/02/2014 05:03 PM, Xue jiufei wrote:
>>> Hi, Dave
>>> On 2014/9/2 7:51, Dave Chinner wrote:
>>>> On Fri, Aug 29, 2014 at 05:57:22PM +0800, Xue jiufei wrote:
>>>>> The patch trys to solve one deadlock problem caused by cluster
>>>>> fs, like ocfs2. And the problem may happen at least in the below
>>>>> situations:
>>>>> 1)Receiving a connect message from other nodes, node queues a
>>>>> work_struct o2net_listen_work.
>>>>> 2)o2net_wq processes this work and calls sock_alloc() to allocate
>>>>> memory for a new socket.
>>>>> 3)It would do direct memory reclaim when available memory is not
>>>>> enough and trigger the inode cleanup. That inode being cleaned up
>>>>> is happened to be ocfs2 inode, so call evict()->ocfs2_evict_inode()
>>>>> ->ocfs2_drop_lock()->dlmunlock()->o2net_send_message_vec(),
>>>>> and wait for the unlock response from master.
>>>>> 4)tcp layer received the response, call o2net_data_ready() and
>>>>> queue sc_rx_work, waiting o2net_wq to process this work.
>>>>> 5)o2net_wq is a single thread workqueue, it process the work one by
>>>>> one. Right now it is still doing o2net_listen_work and cannot handle
>>>>> sc_rx_work. so we deadlock.
>>>>>
>>>>> It is impossible to set GFP_NOFS for memory allocation in sock_alloc().
>>>>> So we use PF_FSTRANS to avoid the task reentering filesystem when
>>>>> available memory is not enough.
>>>>>
>>>>> Signed-off-by: joyce.xue <xuejiufei@huawei.com>
>>>>
>>>> For the second time: use memalloc_noio_save/memalloc_noio_restore.
>>>> And please put a great big comment in the code explaining why you
>>>> need to do this special thing with memory reclaim flags.
>>>>
>>>> Cheers,
>>>>
>>>> Dave.
>>>>
>>> Thanks for your reply. But I am afraid that memalloc_noio_save/
>>> memalloc_noio_restore can not solve my problem. __GFP_IO is cleared
>>> if PF_MEMALLOC_NOIO is set and can avoid doing IO in direct memory
>>> reclaim. However, __GFP_FS is still set that can not avoid pruning
>>> dcache and icache in memory allocation, resulting in the deadlock I
>>> described.
>>
>> You can use PF_MEMALLOC_NOIO to replace PF_FSTRANS, set this flag in
>> ocfs2 and check it in sb shrinker.
> 
> No changes to the superblock shrinker, please. The flag should
> modify the gfp_mask in the struct shrink_control passed to the
> shrinker, just like the noio flag is used in the rest of the mm
> code.
__GFP_FS seemed imply __GFP_IO, can superblock shrinker check
!(sc->gfp_mask & __GFP_IO) and stop?

Thanks,
Junxiao.
> 
> Cheers,
> 
> Dave.
> 

--
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: Junxiao Bi <junxiao.bi@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xuejiufei@huawei.com, Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org,
	"ocfs2-devel@oss.oracle.com" <ocfs2-devel@oss.oracle.com>
Subject: Re: [PATCH] fs/super.c: do not shrink fs slab during direct memory reclaim
Date: Wed, 03 Sep 2014 12:21:24 +0800	[thread overview]
Message-ID: <54069744.7050509@oracle.com> (raw)
In-Reply-To: <20140903031023.GC20473@dastard>

On 09/03/2014 11:10 AM, Dave Chinner wrote:
> On Wed, Sep 03, 2014 at 09:38:31AM +0800, Junxiao Bi wrote:
>> Hi Jiufei,
>>
>> On 09/02/2014 05:03 PM, Xue jiufei wrote:
>>> Hi, Dave
>>> On 2014/9/2 7:51, Dave Chinner wrote:
>>>> On Fri, Aug 29, 2014 at 05:57:22PM +0800, Xue jiufei wrote:
>>>>> The patch trys to solve one deadlock problem caused by cluster
>>>>> fs, like ocfs2. And the problem may happen at least in the below
>>>>> situations:
>>>>> 1)Receiving a connect message from other nodes, node queues a
>>>>> work_struct o2net_listen_work.
>>>>> 2)o2net_wq processes this work and calls sock_alloc() to allocate
>>>>> memory for a new socket.
>>>>> 3)It would do direct memory reclaim when available memory is not
>>>>> enough and trigger the inode cleanup. That inode being cleaned up
>>>>> is happened to be ocfs2 inode, so call evict()->ocfs2_evict_inode()
>>>>> ->ocfs2_drop_lock()->dlmunlock()->o2net_send_message_vec(),
>>>>> and wait for the unlock response from master.
>>>>> 4)tcp layer received the response, call o2net_data_ready() and
>>>>> queue sc_rx_work, waiting o2net_wq to process this work.
>>>>> 5)o2net_wq is a single thread workqueue, it process the work one by
>>>>> one. Right now it is still doing o2net_listen_work and cannot handle
>>>>> sc_rx_work. so we deadlock.
>>>>>
>>>>> It is impossible to set GFP_NOFS for memory allocation in sock_alloc().
>>>>> So we use PF_FSTRANS to avoid the task reentering filesystem when
>>>>> available memory is not enough.
>>>>>
>>>>> Signed-off-by: joyce.xue <xuejiufei@huawei.com>
>>>>
>>>> For the second time: use memalloc_noio_save/memalloc_noio_restore.
>>>> And please put a great big comment in the code explaining why you
>>>> need to do this special thing with memory reclaim flags.
>>>>
>>>> Cheers,
>>>>
>>>> Dave.
>>>>
>>> Thanks for your reply. But I am afraid that memalloc_noio_save/
>>> memalloc_noio_restore can not solve my problem. __GFP_IO is cleared
>>> if PF_MEMALLOC_NOIO is set and can avoid doing IO in direct memory
>>> reclaim. However, __GFP_FS is still set that can not avoid pruning
>>> dcache and icache in memory allocation, resulting in the deadlock I
>>> described.
>>
>> You can use PF_MEMALLOC_NOIO to replace PF_FSTRANS, set this flag in
>> ocfs2 and check it in sb shrinker.
> 
> No changes to the superblock shrinker, please. The flag should
> modify the gfp_mask in the struct shrink_control passed to the
> shrinker, just like the noio flag is used in the rest of the mm
> code.
__GFP_FS seemed imply __GFP_IO, can superblock shrinker check
!(sc->gfp_mask & __GFP_IO) and stop?

Thanks,
Junxiao.
> 
> Cheers,
> 
> Dave.
> 


  reply	other threads:[~2014-09-03  4:21 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29  9:57 [Ocfs2-devel] [PATCH] fs/super.c: do not shrink fs slab during direct memory reclaim Xue jiufei
2014-08-29  9:57 ` Xue jiufei
2014-08-29  9:57 ` Xue jiufei
2014-08-29  9:57 ` Xue jiufei
2014-09-01  6:50 ` [Ocfs2-devel] " Xue jiufei
2014-09-01  6:50   ` Xue jiufei
2014-09-01  6:50   ` Xue jiufei
2014-09-01  6:50   ` Xue jiufei
2014-09-01 23:51 ` [Ocfs2-devel] " Dave Chinner
2014-09-01 23:51   ` Dave Chinner
2014-09-01 23:51   ` Dave Chinner
2014-09-02  9:03   ` [Ocfs2-devel] " Xue jiufei
2014-09-02  9:03     ` Xue jiufei
2014-09-02  9:03     ` Xue jiufei
2014-09-02  9:03     ` Xue jiufei
2014-09-03  1:02     ` [Ocfs2-devel] " Dave Chinner
2014-09-03  1:02       ` Dave Chinner
2014-09-03  1:02       ` Dave Chinner
2014-09-03  1:53       ` [Ocfs2-devel] " Xue jiufei
2014-09-03  1:53         ` Xue jiufei
2014-09-03  1:53         ` Xue jiufei
2014-09-03  1:53         ` Xue jiufei
2014-09-03  1:38     ` [Ocfs2-devel] " Junxiao Bi
2014-09-03  1:38       ` Junxiao Bi
2014-09-03  1:38       ` Junxiao Bi
2014-09-03  3:10       ` [Ocfs2-devel] " Dave Chinner
2014-09-03  3:10         ` Dave Chinner
2014-09-03  3:10         ` Dave Chinner
2014-09-03  4:21         ` Junxiao Bi [this message]
2014-09-03  4:21           ` Junxiao Bi
2014-09-03  4:21           ` Junxiao Bi
2014-09-03  5:02           ` [Ocfs2-devel] " Dave Chinner
2014-09-03  5:02             ` Dave Chinner
2014-09-03  5:02             ` Dave Chinner
2014-09-03  3:30       ` [Ocfs2-devel] " Xue jiufei
2014-09-03  3:30         ` Xue jiufei
2014-09-03  3:30         ` Xue jiufei

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=54069744.7050509@oracle.com \
    --to=junxiao.bi@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=xuejiufei@huawei.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: link
Be 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.