From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 931FDC33CB1 for ; Fri, 17 Jan 2020 17:13:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5EFBF20728 for ; Fri, 17 Jan 2020 17:13:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5EFBF20728 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E09206B04CD; Fri, 17 Jan 2020 12:13:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DB9116B04CE; Fri, 17 Jan 2020 12:13:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCFED6B04CF; Fri, 17 Jan 2020 12:13:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0090.hostedemail.com [216.40.44.90]) by kanga.kvack.org (Postfix) with ESMTP id B60396B04CD for ; Fri, 17 Jan 2020 12:13:37 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 684D7442B for ; Fri, 17 Jan 2020 17:13:37 +0000 (UTC) X-FDA: 76387772874.27.crow42_1f910b5ba2c02 X-HE-Tag: crow42_1f910b5ba2c02 X-Filterd-Recvd-Size: 4143 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Jan 2020 17:13:36 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0C422B2A7; Fri, 17 Jan 2020 17:13:35 +0000 (UTC) Date: Fri, 17 Jan 2020 18:13:31 +0100 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: Andrew Morton Cc: Michal Hocko , Christopher Lameter , LKML , linux-mm@kvack.org Subject: Re: SLUB: purpose of sysfs events on cache creation/removal Message-ID: <20200117171331.GA17179@blackbody.suse.cz> References: <20191127174317.GD26807@dhcp22.suse.cz> <20191204132812.GF25242@dhcp22.suse.cz> <20191204153225.GM25242@dhcp22.suse.cz> <20191204173224.GN25242@dhcp22.suse.cz> <20200106115733.GH12699@dhcp22.suse.cz> <20200109145236.GS4951@dhcp22.suse.cz> <20200109114415.cf01bd3ad30c5c4aec981653@linux-foundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20200109114415.cf01bd3ad30c5c4aec981653@linux-foundation.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello. On Thu, Jan 09, 2020 at 11:44:15AM -0800, Andrew Morton wrote: > I looked at it - there wasn't really any compelling followup. FTR, I noticed udevd consuming non-negligible CPU cycles when doing some cgroup stress testing. And even extrapolating to less artificial situations, the udev events seem to cause useless tickling of udevd. I used the simple script below cat measure.sh </sys/fs/cgroup/memory/grp1/cgroup.procs ; /usr/bin/sleep $1 ; echo 0 >/sys/fs/cgroup/memory/cgroup.procs ; rmdir /sys/fs/cgroup/memory/grp1 ; done } for d in 0.004 0.008 0.016 0.032 0.064 0.128 0.256 0.5 1 ; do echo 0 >/sys/fs/cgroup/cpuacct/system.slice/systemd-udevd.service/cpuacct.usage time sample $d 2>&1 | grep real echo -n "udev " cat /sys/fs/cgroup/cpuacct/system.slice/systemd-udevd.service/cpuacct.usage done EOD and I drew the following ballpark conclusion: 1.7% CPU time at 1 event/s -> 60 event/s 100% cpu (The event is one mkdir/migrate/rmdir sequence. Numbers are from dummy test VM, so take with a grain of salt.) > If this change should be pursued then can we please have a formal > resend? Who's supposed to do that? Regards, Michal --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEEoQaUCWq8F2Id1tNia1+riC5qSgFAl4h6zYACgkQia1+riC5 qSgKoA//ZHOaTtyAwAzIU0cfBkSxBLjGxpA8TqqGk7nRIhCI9CK9bQuIifOOfWQV YYL3ApPANU6o+bYOxM8xXe4G2TXZBF/Q23jjORGv7C2bRwldTNvYZ0dvYwq0bQ3n l0pXy1R8IDxSB3CPgUE6b7taBjrIuMds63i7MhwZ3CxW540cUGm8mPpB9RE5kinh IGduSTM73kbVypVHuw1hMhZu0QueepUAawpZIFK6wbOsade0NE0p6Pq0xxVCRp+B cYq9O161YcED0HIR+fdC8q63VN8tHJJovKJbVocrzweEonSmPdoBap32guhlMFTQ rPs3tD6MV0SIOfqTN4A6b7IHrxqiWYs4aqktiCt1iQj2WDKwVIVDweA73vyehQXa wXZE+mak1gNjxwKAWAtsMLZl7TupqPrwbZIUq2vNb/ob+zQ+wKfxHfq0BMRMG/v5 /QPzbZalrzfOZvtjgMrZXHY6eNfHUm7PkJWEHlY3WshN7Crb1tp0+UOi6DyexXsc Y0V3JAP3gUh2Y+hTZVQwmutNt7zDLSqo0F14SRN3bNhVL/3Hy59e6tIqVktJHq8b ZMwnpvclnBWdcLzoH5hq7PsAnNJDhdRRAFsN3xFfIjmIFEIN07fXTxWSrpasYohC g7eC1qGJf2vSWdvpj8kVLiaPRX6wYK0sUg4duwQbyg7Y26RG0JU= =VSEp -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu--