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;
From:   Roman Gushchin <guro@fb.com>
To:     Andrew Morton <akpm@linux-foundation.org>
CC:     Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>,
        Michal Hocko <mhocko@kernel.org>, Chris Mason <clm@fb.com>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
        "vdavydov.dev@gmail.com" <vdavydov.dev@gmail.com>
Subject: Re: [PATCH 1/2] Revert "mm: don't reclaim inodes with many attached
 pages"
Thread-Topic: [PATCH 1/2] Revert "mm: don't reclaim inodes with many attached
 pages"
Thread-Index: AQHUuFKyWLaITMbS90mKhttYYyCJLqXHu+eAgADdi4CAAH9ygIAAHdwAgAC+jQCACjmaAIABQTOAgABH/oCAADEXgIAAp1YAgABRyYA=
Date:   Sat, 9 Feb 2019 03:42:30 +0000
Message-ID: <20190209034223.GA2591@castle.DHCP.thefacebook.com>
References: <25EAF93D-BC63-4409-AF21-F45B2DDF5D66@fb.com>
 <20190131013403.GI4205@dastard> <20190131091011.GP18811@dhcp22.suse.cz>
 <20190131185704.GA8755@castle.DHCP.thefacebook.com>
 <20190131221904.GL4205@dastard> <20190207102750.GA4570@quack2.suse.cz>
 <20190207213727.a791db810341cec2c013ba93@linux-foundation.org>
 <20190208095507.GB6353@quack2.suse.cz>
 <20190208125049.GA11587@quack2.suse.cz>
 <20190208144944.082a771e84f02a77bad3e292@linux-foundation.org>
In-Reply-To: <20190208144944.082a771e84f02a77bad3e292@linux-foundation.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2620:10d:c090:180::1:db87]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;BYAPR15MB3112;20:856hCyX4fJdMdWcIzpwY+PDNB1XYpsu70rELFTwp/wBEU2Ks+XNSQySv+jcKC57i4BA3Hq654Z/vkn+h3gjaxTlk7eOOevC1eJa9LClIVhofqBeezzyJ14mTwBBII+h2gNZSoS54xlGy/rkW2yDRxqcPg7KLnOavuBZLaoATEIo=
x-ms-office365-filtering-correlation-id: 7b6751be-f96e-4da0-915a-08d68e409e57
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020);SRVR:BYAPR15MB3112;
x-ms-traffictypediagnostic: BYAPR15MB3112:
x-microsoft-antispam-prvs: <BYAPR15MB311218F81DB0959FAF368AD8BE6A0@BYAPR15MB3112.namprd15.prod.outlook.com>
x-forefront-prvs: 09435FCA72
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(396003)(136003)(376002)(39860400002)(346002)(366004)(199004)(189003)(97736004)(8676002)(106356001)(229853002)(6436002)(6116002)(446003)(4326008)(81166006)(11346002)(81156014)(8936002)(186003)(6916009)(6512007)(9686003)(256004)(478600001)(5024004)(14444005)(6486002)(68736007)(105586002)(33656002)(14454004)(386003)(46003)(33896004)(53936002)(99286004)(25786009)(6506007)(76176011)(71200400001)(52116002)(102836004)(71190400001)(93886005)(486006)(2906002)(6246003)(86362001)(476003)(305945005)(7736002)(316002)(54906003)(1076003);DIR:OUT;SFP:1102;SCL:1;SRVR:BYAPR15MB3112;H:BYAPR15MB2631.namprd15.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
received-spf: None (protection.outlook.com: fb.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: vjLKh+N40P1WdqiNyE8of39w7Fj7AloVFPIWXny4F4Bxt3tBLR2Xpt5ToNi7IX9iSmjLGFV9+nrrzTqABJ3aEoxUTvC0/Ik0YusttJ1zcX0k4+nO+7nmMHJG/mVgLqMxNBvxoHBYPDa+549BGULswJFH+2QcxqgFgJrhKoOzy6YkCrWVN5xCIHoLjrxHda1bvOeoePtCeOpw6pP4NT0YJFDqHoxhsFR2CBHnbYidd2XAzVPm307n9vHSWTVh2ZpPKqOabRMxCD4xkDNqIgCzYzV2MW/5JfFf7jA6Or1C/bFTOP3odhJyaysVm3y/WVkzhl9oYwss5vzzUl4TMNpBVEMKd2AwDSzBvpCGvbrVbFZ++TJrwfqakQYAEbfp4rDBc9SgdFi5/vRlLZ+cliKv7peogm+v0KUXA59WeL66VIM=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <732A74A8901BE749BECB4649E223D905@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b6751be-f96e-4da0-915a-08d68e409e57
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2019 03:42:29.8119
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3112
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-02-09_03:,,
 signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Feb 08, 2019 at 02:49:44PM -0800, Andrew Morton wrote:
> On Fri, 8 Feb 2019 13:50:49 +0100 Jan Kara <jack@suse.cz> wrote:
>=20
> > > > Has anyone done significant testing with Rik's maybe-fix?
> > >=20
> > > I will give it a spin with bonnie++ today. We'll see what comes out.
> >=20
> > OK, I did a bonnie++ run with Rik's patch (on top of 4.20 to rule out o=
ther
> > differences). This machine does not show so big differences in bonnie++
> > numbers but the difference is still clearly visible. The results are
> > (averages of 5 runs):
> >=20
> > 		 Revert			Base			Rik
> > SeqCreate del    78.04 (   0.00%)	98.18 ( -25.81%)	90.90 ( -16.48%)
> > RandCreate del   87.68 (   0.00%)	95.01 (  -8.36%)	87.66 (   0.03%)
> >=20
> > 'Revert' is 4.20 with "mm: don't reclaim inodes with many attached page=
s"
> > and "mm: slowly shrink slabs with a relatively small number of objects"
> > reverted. 'Base' is the kernel without any reverts. 'Rik' is a 4.20 wit=
h
> > Rik's patch applied.
> >=20
> > The numbers are time to do a batch of deletes so lower is better. You c=
an see
> > that the patch did help somewhat but it was not enough to close the gap
> > when files are deleted in 'readdir' order.
>=20
> OK, thanks.
>=20
> I guess we need a rethink on Roman's fixes.   I'll queued the reverts.

Agree.

I still believe that we should cause the machine-wide memory pressure
to clean up any remains of dead cgroups, and Rik's patch is a step into
the right direction. But we need to make some experiments and probably
some code changes here to guarantee that we don't regress on performance.

>=20
>=20
> BTW, one thing I don't think has been discussed (or noticed) is the
> effect of "mm: don't reclaim inodes with many attached pages" on 32-bit
> highmem machines.  Look why someone added that code in the first place:
>=20
> : commit f9a316fa9099053a299851762aedbf12881cff42
> : Author: Andrew Morton <akpm@digeo.com>
> : Date:   Thu Oct 31 04:09:37 2002 -0800
> :=20
> :     [PATCH] strip pagecache from to-be-reaped inodes
> :    =20
> :     With large highmem machines and many small cached files it is possi=
ble
> :     to encounter ZONE_NORMAL allocation failures.  This can be demonstr=
ated
> :     with a large number of one-byte files on a 7G machine.
> :    =20
> :     All lowmem is filled with icache and all those inodes have a small
> :     amount of highmem pagecache which makes them unfreeable.
> :    =20
> :     The patch strips the pagecache from inodes as they come off the tai=
l of
> :     the inode_unused list.
> :    =20
> :     I play tricks in there peeking at the head of the inode_unused list=
 to
> :     pick up the inode again after running iput().  The alternatives see=
med
> :     to involve more widespread changes.
> :    =20
> :     Or running invalidate_inode_pages() under inode_lock which would be=
 a
> :     bad thing from a scheduling latency and lock contention point of vi=
ew.
>=20
> I guess I shold have added a comment.  Doh.
>=20

It's a very useful link.

Thanks!