Received: by 10.192.165.156 with SMTP id m28csp361254imm; Fri, 13 Apr 2018 00:02:30 -0700 (PDT) X-Google-Smtp-Source: AIpwx48//hYC3aN0f00mmBtqcxgd9U167gdeaBiB6d4gXm13dtxn5isLy5AsQUaZlCEazzVgeI9p X-Received: by 2002:a17:902:3c5:: with SMTP id d63-v6mr2568348pld.163.1523602950299; Fri, 13 Apr 2018 00:02:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523602950; cv=none; d=google.com; s=arc-20160816; b=mQvqOBkcqr7SI9xJwt+DlmUFVXjSxSbJYJ0VdPlYkN2eoeX03YyDzxusasoRQyYZ1j BK8z871Kp8C0wKoOCsglN5pvg9KFxoesgqR3UzJ5NGzA2ehz0RxJifyHtTy5trD8uuHp I9garxC6At+ZBagjRJ7V7qT3wxWBKQPgUfJ61Dr13AD+Z5Kok3OwR2GBxlNYvQs7Ug9d RFvgA9jISkzYawdl1OBNBYKwXDArHj4CS3pUrsxxeo83qMRJU381V2kiVyiIk0I7NYtn hYwpLcYH85aLiheoh0RMnDid2M9Q+eOKy9vZG3AGvLKfcKaRXD8wG1lNfK1wFV9W9TAl /snA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=Aouvkk9OUChtt5iT2VnL5XvJf16cC3Qby0ZqD4nRU2I=; b=wVHuZt1FyGP7dALcBzHBoOFtbane+vKjb05pdrU9YOgWeDNLe66CX0X+LpZ8b67dTV pJbcajuqOsa7islF4aHfU59tk4VavV/vXFhKtYlTzryLjqQJXySsW5vbz3ZAXQPg/Aqs lyaurfYjma2qXyNCVy2sTjj6nOApukXzNpYcKfcWG14QCzzrdwoinLi5yaAk/fGeygSP LUgRJfmQW9NdQ2NcMpBRrYphO4mFiZHfxZf//wu4nYSXI2Epj2lMAXglsMBRWnu8xdwj 6cLTRdSiVDGhLPZIEHllvtDdRdBjArd8oTR67khw2jyAWYVY7yUhJMviDiIUFvJO02Yf 6NEA== 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 l192si2227484pge.365.2018.04.13.00.02.16; Fri, 13 Apr 2018 00:02:30 -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 S1753630AbeDMG7v (ORCPT + 99 others); Fri, 13 Apr 2018 02:59:51 -0400 Received: from mx2.suse.de ([195.135.220.15]:42243 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750973AbeDMG7t (ORCPT ); Fri, 13 Apr 2018 02:59:49 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8233EAE82; Fri, 13 Apr 2018 06:59:47 +0000 (UTC) Date: Fri, 13 Apr 2018 08:59:44 +0200 From: Michal Hocko To: Roman Gushchin Cc: Vlastimil Babka , linux-mm@kvack.org, Andrew Morton , Alexander Viro , Johannes Weiner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Linux API Subject: Re: [PATCH 1/3] mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES Message-ID: <20180413065944.GE17484@dhcp22.suse.cz> References: <20180305133743.12746-1-guro@fb.com> <20180305133743.12746-2-guro@fb.com> <08524819-14ef-81d0-fa90-d7af13c6b9d5@suse.cz> <20180411135624.GA24260@castle.DHCP.thefacebook.com> <46dbe2a5-e65f-8b72-f835-0210bc445e52@suse.cz> <20180412145702.GB30714@castle.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180412145702.GB30714@castle.DHCP.thefacebook.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 12-04-18 15:57:03, Roman Gushchin wrote: > On Thu, Apr 12, 2018 at 08:52:52AM +0200, Vlastimil Babka wrote: [...] > > We would be just making the reported values more precise wrt reality. > > It depends on if we believe that only slab memory can be reclaimable > or not. If yes, this is true, otherwise not. > > My guess is that some drivers (e.g. networking) might have buffers, > which are reclaimable under mempressure, and are allocated using > the page allocator. But I have to look closer... Well, we have many direct page allocator users which are not accounted in vmstat. Some of those use their specific accounting (e.g. network buffers, some fs metadata a many others). In the ideal world MM layer would know about those but... Anyway, this particular case is quite clear, no? We _use_ kmalloc so this is slab allocator. We just misaccount it. -- Michal Hocko SUSE Labs