Received: by 10.213.65.68 with SMTP id h4csp2437887imn; Thu, 5 Apr 2018 15:13:12 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+Ul9XrS5JhNfEUsbZq4v4cbfsQaN15TTp0VVTCWo5NXoSq89xaM/m1279BDUnHK+Hqlh13 X-Received: by 10.101.64.7 with SMTP id f7mr16116043pgp.216.1522966392740; Thu, 05 Apr 2018 15:13:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522966392; cv=none; d=google.com; s=arc-20160816; b=fqfBE5SPt/vkT3/NeAqzcPhrtvpYQ0dJPVIJljUq4FDL70Ju4Tth3JM0vh/9Ijo+Vz yBvg2GZEVgfTPOZFH98twBkLpjlcnYJy4ECHaLEMChrwBq+Pl7K0pLeAfohprPc7QlaA dh5iSuuz50Q9PKiOLWftln2RiXCDjvlF3nWenmDxdBF2WG3kgZ1ad9f/zQAxrxX5UK6p fhqi7Japd7c6k4ghO12/a4uUKTNxqaeD3CH0YXQ+JJZjtGepx74M6qMQsKJ8UBVwo3xv x1X8aHXwSA5yTOu6ZsgqQmFbqSsf3Wcrl2mtX89KWQCy4jRggxYlw+nn/TBppfcajLuk 1qvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=gsA1ujb4+aTVATcWU2voAbv1+D2OsW59MiqvTe+tSE4=; b=rgO93OMfY91SCKzwGomNMMGKmnhgBG6FrrVfw8nIO7REB00M2mzZqrzUYwmu89jova GbAjJ4BF7zmMJqhX+MjEfxPKLFZ7nOEBA9y4FPgGcZ3QjRxKkowMDnYktV7F5Jf7X/IX UywVXmYYCEoXzyM9+ku5LmN5yVu6STupGAmre2hsM0MefIyG8V5jdfXLeTRXajK5ZHY8 RKG6dzOLBEIULQePtScekCIb7s7PMB1eng9m8/Hq5luhLvB1tuL4ivv5PNV8px5sgvY4 KoATIdjiRza2qod//KUSG//1BbSP15W8vwngbv1pZo5YRAyWGCR1GUxFQQKV5RQUIcLr kxmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b8-v6si7438729plm.590.2018.04.05.15.12.58; Thu, 05 Apr 2018 15:13:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754093AbeDEWL0 (ORCPT + 99 others); Thu, 5 Apr 2018 18:11:26 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:56640 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752469AbeDEWLZ (ORCPT ); Thu, 5 Apr 2018 18:11:25 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.71]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id A1887D93; Thu, 5 Apr 2018 22:11:24 +0000 (UTC) Date: Thu, 5 Apr 2018 15:11:23 -0700 From: Andrew Morton To: Al Viro Cc: Roman Gushchin , linux-mm@kvack.org, Michal Hocko , Johannes Weiner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 3/3] dcache: account external names as indirectly reclaimable memory Message-Id: <20180405151123.df20d12168d8a38f7a6b02b5@linux-foundation.org> In-Reply-To: <20180313004532.GU30522@ZenIV.linux.org.uk> References: <20180305133743.12746-1-guro@fb.com> <20180305133743.12746-5-guro@fb.com> <20180312211742.GR30522@ZenIV.linux.org.uk> <20180312223632.GA6124@castle> <20180313004532.GU30522@ZenIV.linux.org.uk> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Mar 2018 00:45:32 +0000 Al Viro wrote: > On Mon, Mar 12, 2018 at 10:36:38PM +0000, Roman Gushchin wrote: > > > Ah, I see... > > > > I think, it's better to account them when we're actually freeing, > > otherwise we will have strange path: > > (indirectly) reclaimable -> unreclaimable -> free > > > > Do you agree? > > > +static void __d_free_external_name(struct rcu_head *head) > > +{ > > + struct external_name *name; > > + > > + name = container_of(head, struct external_name, u.head); > > + > > + mod_node_page_state(page_pgdat(virt_to_page(name)), > > + NR_INDIRECTLY_RECLAIMABLE_BYTES, > > + -ksize(name)); > > + > > + kfree(name); > > +} > > Maybe, but then you want to call that from __d_free_external() and from > failure path in __d_alloc() as well. Duplicating something that convoluted > and easy to get out of sync is just asking for trouble. So.. where are we at with this issue?