Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp163640pxa; Tue, 18 Aug 2020 19:52:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwb7M+mL2mYhUsRqWzwJ7VAV+a9+DakP6mESd8Z9QQ5LLFMsCOSiNULf+UPTjI/PY+hGv6L X-Received: by 2002:a17:906:f8d9:: with SMTP id lh25mr24229028ejb.458.1597805573302; Tue, 18 Aug 2020 19:52:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597805573; cv=none; d=google.com; s=arc-20160816; b=POodKtGph6RkFwqYIUJaWVuzOuIa6ZzRdtA/We55VpBOw6OgtcOEz8YJvoowkxP97j eAM5/QsG8KOlbH/K6VxyiK8i6lhdmxRKH7Gtql1nGJ++1bC2rzIvXf2TSLMjzij4I0ho bp9c7vYMi0EUo/LYuctproAlOuyHH/TDRUFksrISSKTyz0DK/S53efnzuV3zRUprzu7T /QgFiunNoHNN3UU3U/n7nqHQF+wXSnNUtX4uw5r8iWEmD7FjJex1OglSGNZWfAJmEvq5 ZWFAHFtdDlhyiG0gwgPqMIyAkzuxExmbRR+Hr2Z4uovvDGCnE+JoRNv/rs6v/nxJKP8L iT/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=axHVELCy16jROJqkyzUqt9eiYioUruhvfsckgk8BFXs=; b=L84VNh5dHTGGF9ARuIGGkV6Lv8LMYL4o+w24U5R8k4cSDCImJWqhIrApWuhOyOilxQ Ml9xTDylhNP0R5ZdXYaa9zLaXR4V7VYNC+8lT80fOELes1peLZReWbAnUBaiXeZDYfMd HY5HuFL/nY/s/qMFf+aqvWuJHN2W/rhAEKTrtC6PL6XONc+g5ABJpiMuFrtYr1HiCCk2 4Ew559rHuG91omtwTSR7WeojE+98P0gQ/H2DvjVN6jnIhzZj+sKgGihcQsFmohYQZSqt nG8DsV3o14mjh+L9hwZsYCvEx2DPPkgJIqJMmGQqEuT6jSnOvV3E6bqoa1b1Y0+ucI78 afxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n1si14558127ejb.57.2020.08.18.19.52.27; Tue, 18 Aug 2020 19:52:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726977AbgHSC3T (ORCPT + 99 others); Tue, 18 Aug 2020 22:29:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726372AbgHSC3T (ORCPT ); Tue, 18 Aug 2020 22:29:19 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D12E3C061389; Tue, 18 Aug 2020 19:29:18 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k8Dqd-000c0L-B6; Wed, 19 Aug 2020 02:29:07 +0000 Date: Wed, 19 Aug 2020 03:29:07 +0100 From: Al Viro To: Linus Torvalds Cc: Miklos Szeredi , Steven Whitehouse , David Howells , linux-fsdevel , Karel Zak , Jeff Layton , Miklos Szeredi , Nicolas Dichtel , Christian Brauner , Lennart Poettering , Linux API , Ian Kent , LSM , Linux Kernel Mailing List Subject: Re: file metadata via fs API Message-ID: <20200819022907.GE1236603@ZenIV.linux.org.uk> References: <52483.1597190733@warthog.procyon.org.uk> <066f9aaf-ee97-46db-022f-5d007f9e6edb@redhat.com> <94f907f0-996e-0456-db8a-7823e2ef3d3f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 18, 2020 at 11:51:25AM -0700, Linus Torvalds wrote: > I think people who have problems parsing plain ASCII text are just > wrong. It's not that expensive. The thing that makes /proc/mounts > expensive is not the individual lines - it's that there are a lot of > them. It is expensive - if you use strdup() all over the place, do asprintf() equivalents for concatenation, etc. IOW, you can write BASIC (or javascript) in any language... systemd used to be that bad - exactly in parsing /proc/mounts; I hadn't checked that code lately, so it's possible that it had gotten better, but about 4 years ago it had been awful. OTOH, at that time I'd been looking at the atrocities kernel-side (in fs/pnode.c), where on realistic setups we had O(N^2) allocations done, with all but O(N) of them ending up freed before anyone could see them. So it's not as if they had a monopoly on bloody awful code...