Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753612AbcDOLOm (ORCPT ); Fri, 15 Apr 2016 07:14:42 -0400 Received: from mail.fireflyinternet.com ([87.106.93.118]:52708 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753617AbcDOLOj (ORCPT ); Fri, 15 Apr 2016 07:14:39 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Date: Fri, 15 Apr 2016 12:14:31 +0100 From: Chris Wilson To: Roman Peniaev Cc: intel-gfx@lists.freedesktop.org, Joonas Lahtinen , Tvrtko Ursulin , Daniel Vetter , Andrew Morton , David Rientjes , Joonsoo Kim , Mel Gorman , Toshi Kani , Shawn Lin , linux-mm@kvack.org, "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] mm/vmalloc: Keep a separate lazy-free list Message-ID: <20160415111431.GL19990@nuc-i3427.alporthouse.com> Mail-Followup-To: Chris Wilson , Roman Peniaev , intel-gfx@lists.freedesktop.org, Joonas Lahtinen , Tvrtko Ursulin , Daniel Vetter , Andrew Morton , David Rientjes , Joonsoo Kim , Mel Gorman , Toshi Kani , Shawn Lin , linux-mm@kvack.org, "linux-kernel@vger.kernel.org" References: <1460444239-22475-1-git-send-email-chris@chris-wilson.co.uk> <20160414134926.GD19990@nuc-i3427.alporthouse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1807 Lines: 49 On Thu, Apr 14, 2016 at 04:44:48PM +0200, Roman Peniaev wrote: > On Thu, Apr 14, 2016 at 3:49 PM, Chris Wilson wrote: > > On Thu, Apr 14, 2016 at 03:13:26PM +0200, Roman Peniaev wrote: > >> Hi, Chris. > >> > >> Is it made on purpose not to drop VM_LAZY_FREE flag in > >> __purge_vmap_area_lazy()? With your patch va->flags > >> will have two bits set: VM_LAZY_FREE | VM_LAZY_FREEING. > >> Seems it is not that bad, because all other code paths > >> do not care, but still the change is not clear. > > > > Oh, that was just a bad deletion. > > > >> Also, did you consider to avoid taking static purge_lock > >> in __purge_vmap_area_lazy() ? Because, with your change > >> it seems that you can avoid taking this lock at all. > >> Just be careful when you observe llist as empty, i.e. > >> nr == 0. > > > > I admit I only briefly looked at the lock. I will be honest and say I > > do not fully understand the requirements of the sync/force_flush > > parameters. > > if sync: > o I can wait for other purge in progress > (do not care if purge_lock is dropped) > > o purge fragmented blocks > > if force_flush: > o even nothing to purge, flush TLB, which is costly. > (again sync-like is implied) > > > purge_fragmented_blocks() manages per-cpu lists, so that looks safe > > under its own rcu_read_lock. > > > > Yes, it looks feasible to remove the purge_lock if we can relax sync. > > what is still left is waiting on vmap_area_lock for !sync mode. > but probably is not that bad. Ok, that's bit beyond my comfort zone with a patch to change the free list handling. I'll chicken out for the time being, atm I am more concerned that i915.ko may call set_page_wb() frequently on individual pages. -Chris -- Chris Wilson, Intel Open Source Technology Centre