From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by kanga.kvack.org (Postfix) with ESMTP id B24FF6B0035 for ; Thu, 3 Jul 2014 03:34:47 -0400 (EDT) Received: by mail-la0-f44.google.com with SMTP id ty20so7891613lab.3 for ; Thu, 03 Jul 2014 00:34:46 -0700 (PDT) Received: from lgemrelse6q.lge.com (LGEMRELSE6Q.lge.com. [156.147.1.121]) by mx.google.com with ESMTP id i6si15416302lbd.45.2014.07.03.00.34.44 for ; Thu, 03 Jul 2014 00:34:46 -0700 (PDT) Message-ID: <53B50791.50208@lge.com> Date: Thu, 03 Jul 2014 16:34:41 +0900 From: Gioh Kim MIME-Version: 1.0 Subject: Re: [RFC] CMA page migration failure due to buffers on bh_lru References: <53A8D092.4040801@lge.com> <53ACAB82.6020201@lge.com> <53B06DD0.8030106@codeaurora.org> <53B209BA.8010106@lge.com> <53B216C5.8020503@codeaurora.org> <20140701224621.bb6a5157.akpm@linux-foundation.org> In-Reply-To: <20140701224621.bb6a5157.akpm@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton , Laura Abbott Cc: Michal Nazarewicz , Marek Szyprowski , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim , Mel Gorman , =?UTF-8?B?7J206rG07Zi4?= , Hugh Dickins Hi, Laura, I has replaced the evict_bh_lrus(bh) with invalidate_bh_lrus() and it is working fine. How about submit new patch with invalidate_bh_lrus()? I would appreciate it. 2014-07-02 i??i?? 2:46, Andrew Morton i?' e,?: > On Mon, 30 Jun 2014 19:02:45 -0700 Laura Abbott wrote: > >> On 6/30/2014 6:07 PM, Gioh Kim wrote: >>> Hi,Laura. >>> >>> I have a question. >>> >>> Does the __evict_bh_lru() not need bh_lru_lock()? >>> The get_cpu_var() has already preenpt_disable() and can prevent other thread. >>> But get_cpu_var cannot prevent IRQ context such like page-fault. >>> I think if a page-fault occured and a file is read in IRQ context it can change cpu-lru. >>> >>> Is my concern correct? >>> >>> >> >> __evict_bh_lru is called via on_each_cpu_cond which I believe will disable irqs. >> I based the code on the existing invalidate_bh_lru which did not take the bh_lru_lock >> either. It's possible I missed something though. > > I fear that running on_each_cpu() within try_to_free_buffers() is going > to be horridly expensive in some cases. > > Maybe CMA can use invalidate_bh_lrus() to shoot down everything before > trying the allocation attempt. That should increase the success rate > greatly and doesn't burden page reclaim. The bh LRU isn't terribly > important from a performance point of view, so emptying it occasionally > won't hurt. > > -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932362AbaGCHeq (ORCPT ); Thu, 3 Jul 2014 03:34:46 -0400 Received: from LGEMRELSE6Q.lge.com ([156.147.1.121]:36342 "EHLO lgemrelse6q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932091AbaGCHeo (ORCPT ); Thu, 3 Jul 2014 03:34:44 -0400 X-Original-SENDERIP: 10.178.33.69 X-Original-MAILFROM: gioh.kim@lge.com Message-ID: <53B50791.50208@lge.com> Date: Thu, 03 Jul 2014 16:34:41 +0900 From: Gioh Kim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andrew Morton , Laura Abbott CC: Michal Nazarewicz , Marek Szyprowski , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim , Mel Gorman , =?UTF-8?B?7J206rG07Zi4?= , Hugh Dickins Subject: Re: [RFC] CMA page migration failure due to buffers on bh_lru References: <53A8D092.4040801@lge.com> <53ACAB82.6020201@lge.com> <53B06DD0.8030106@codeaurora.org> <53B209BA.8010106@lge.com> <53B216C5.8020503@codeaurora.org> <20140701224621.bb6a5157.akpm@linux-foundation.org> In-Reply-To: <20140701224621.bb6a5157.akpm@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Laura, I has replaced the evict_bh_lrus(bh) with invalidate_bh_lrus() and it is working fine. How about submit new patch with invalidate_bh_lrus()? I would appreciate it. 2014-07-02 오후 2:46, Andrew Morton 쓴 글: > On Mon, 30 Jun 2014 19:02:45 -0700 Laura Abbott wrote: > >> On 6/30/2014 6:07 PM, Gioh Kim wrote: >>> Hi,Laura. >>> >>> I have a question. >>> >>> Does the __evict_bh_lru() not need bh_lru_lock()? >>> The get_cpu_var() has already preenpt_disable() and can prevent other thread. >>> But get_cpu_var cannot prevent IRQ context such like page-fault. >>> I think if a page-fault occured and a file is read in IRQ context it can change cpu-lru. >>> >>> Is my concern correct? >>> >>> >> >> __evict_bh_lru is called via on_each_cpu_cond which I believe will disable irqs. >> I based the code on the existing invalidate_bh_lru which did not take the bh_lru_lock >> either. It's possible I missed something though. > > I fear that running on_each_cpu() within try_to_free_buffers() is going > to be horridly expensive in some cases. > > Maybe CMA can use invalidate_bh_lrus() to shoot down everything before > trying the allocation attempt. That should increase the success rate > greatly and doesn't burden page reclaim. The bh LRU isn't terribly > important from a performance point of view, so emptying it occasionally > won't hurt. > >