Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4660422ybe; Mon, 9 Sep 2019 12:31:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxLqk5mkVYbl8376HtSEfrp3ZQ6NeAtyZAZ4zECgehB7EvSs9MLmTPqlSlLQ3AGpIQbJr6G X-Received: by 2002:a50:b885:: with SMTP id l5mr25482134ede.190.1568057470912; Mon, 09 Sep 2019 12:31:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568057470; cv=none; d=google.com; s=arc-20160816; b=x3uDDTfb2V6sxmgJ6lb3NUpb/ohz+VQSqOzGjRyRlRxaRHob9tt2Ao7RaexUrVXhkv x7WdYePOJ3bbXtmHlpLVB8RNneuxB4JH7EfDWixdkMZw4kTdTEgEogoVtjYM/VxQeWjp /aPCSzj5ePN/vXC8n4evRk1lvtuSbDt4/fCdlO5bG811LaQNlcnETuQCuohAkMPAiDSv QIA7/M+bsyAMnhEdkFZPtWcEQ9XXTUItJIjR9+xkxAfRHxEJEMn8PPziaVOxxN6Cy0F0 0d75UTAWYKViZo02IcQ319gUb9TtwKfrArPYFw2udSv8YUhG2XFzD1PjQNaw0Kz/zv+l dUBw== 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; bh=1FI4BmX5lmykNwsTiFgyDoCmIE6oyKz/YYXfm05dzuM=; b=P/8K9I6Ar1sGDiG3qBq0nd+THd5tas5FPXHNnuCQUHBCcPI45pIZ/lmfMjt5My8wWv pxGeFUcxvaKSZohsrwmSmPmtQLuBGrbwNC7AIwiFOrNlReNDBwnhE2RsO3TDXTXq2rWR 4FArFJ9R4oHyWjZgfOLUAuPEyFLHXzcDFx+5a1sY5OcNZ4yxmDfLdR6Usq1+/IgjUPgK 8ME8n6BSyXGtQtbiorVrwg5kEAxQwd5D9jmfdEUxCacrHUN2C2vq1Br1NZYN6KHc45vF H/ltt/lBxRLcQp1UxwdA3tqFbiaIXubiGtS2Kw9U4s2bUgQozrxEPfqq3T4Jekn9c6yt C39g== 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 rs27si8285738ejb.379.2019.09.09.12.30.14; Mon, 09 Sep 2019 12:31:10 -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 S1730912AbfIHVqK (ORCPT + 99 others); Sun, 8 Sep 2019 17:46:10 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:45980 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730816AbfIHVqK (ORCPT ); Sun, 8 Sep 2019 17:46:10 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.2 #3 (Red Hat Linux)) id 1i750T-00022V-AW; Sun, 08 Sep 2019 21:46:01 +0000 Date: Sun, 8 Sep 2019 22:46:01 +0100 From: Al Viro To: kernel test robot Cc: David Howells , Hugh Dickins , LKML , linux-fsdevel@vger.kernel.org, lkp@01.org Subject: Re: [vfs] 8bb3c61baf: vm-scalability.median -23.7% regression Message-ID: <20190908214601.GC1131@ZenIV.linux.org.uk> References: <20190903084122.GH15734@shao2-debian> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190903084122.GH15734@shao2-debian> User-Agent: Mutt/1.12.0 (2019-05-25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 03, 2019 at 04:41:22PM +0800, kernel test robot wrote: > Greeting, > > FYI, we noticed a -23.7% regression of vm-scalability.median due to commit: > > > commit: 8bb3c61bafa8c1cd222ada602bb94ff23119e738 ("vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount API") > https://kernel.googlesource.com/pub/scm/linux/kernel/git/viro/vfs.git work.mount > > in testcase: vm-scalability > on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 128G memory > with following parameters: > > runtime: 300s > size: 16G > test: shm-pread-rand > cpufreq_governor: performance > ucode: 0xb000036 That thing loses size=... option. Both size= and nr_blocks= affect the same thing (->max_blocks), but the parser keeps track of the options it has seen and applying the parsed data to superblock checks only whether nr_blocks= had been there. IOW, size= gets parsed, but the result goes nowhere. I'm not sure whether it's better to fix the patch up or redo it from scratch - it needs to be carved up anyway and it's highly non-transparent, so I'm probably going to replace the damn thing entirely with something that would be easier to follow.