Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751529AbaBFXWX (ORCPT ); Thu, 6 Feb 2014 18:22:23 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:49768 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751019AbaBFXWU (ORCPT ); Thu, 6 Feb 2014 18:22:20 -0500 Date: Thu, 6 Feb 2014 15:22:19 -0800 From: Andrew Morton To: David Rientjes Cc: Raghavendra K T , Fengguang Wu , David Cohen , Al Viro , Damien Ramonda , Jan Kara , Linus , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages Message-Id: <20140206152219.45c2039e5092c8ea1c31fd38@linux-foundation.org> In-Reply-To: References: <1390388025-1418-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com> <20140206145105.27dec37b16f24e4ac5fd90ce@linux-foundation.org> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 6 Feb 2014 14:58:21 -0800 (PST) David Rientjes wrote: > > > +#define MAX_REMOTE_READAHEAD 4096UL > > > /* > > > * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a > > > * sensible upper limit. > > > */ > > > unsigned long max_sane_readahead(unsigned long nr) > > > { > > > - return min(nr, (node_page_state(numa_node_id(), NR_INACTIVE_FILE) > > > - + node_page_state(numa_node_id(), NR_FREE_PAGES)) / 2); > > > + unsigned long local_free_page; > > > + int nid; > > > + > > > + nid = numa_node_id(); > > If you're intending this to be cached for your calls into > node_page_state() you need nid = ACCESS_ONCE(numa_node_id()). ugh. That's too subtle and we didn't even document it. We could put the ACCESS_ONCE inside numa_node_id() I assume but we still have the same problem as smp_processor_id(): the numa_node_id() return value is wrong as soon as you obtain it if running preemptibly. We could plaster Big Fat Warnings all over the place or we could treat numa_node_id() and derivatives in the same way as smp_processor_id() (which is a huge pain). Or something else, but we've left a big hand grenade here and Raghavendra won't be the last one to pull the pin? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/