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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F025C4345F for ; Sat, 4 May 2024 15:33:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AB2F6B0088; Sat, 4 May 2024 11:33:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15BE66B0089; Sat, 4 May 2024 11:33:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 049C66B008A; Sat, 4 May 2024 11:32:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CF47F6B0088 for ; Sat, 4 May 2024 11:32:59 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 83B791A1031 for ; Sat, 4 May 2024 15:32:59 +0000 (UTC) X-FDA: 82081106478.28.2E4DD03 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id DFD61120007 for ; Sat, 4 May 2024 15:32:57 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=TZ6mwWsd; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf29.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714836778; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Fwo30BJD0LMI1tLE8XVt3aEB3VgL8ElIaDGcWRFzgWc=; b=KjiDdcnTAAcbqe7sLALOIzIgtjq4zS9eSiwqRlqrsUjWXk8q1Qu8gHyk54mMmOhQsRou72 EgL5mxlENNAkRViVRA+pXwFB/38yiXJX4uCxnQeD5e8fAPAC7G3NruAj8logoe+iVNQr/s TNxzsrr8VxyZ/bxrfX2/DHRxOOPjLEc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=TZ6mwWsd; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf29.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714836778; a=rsa-sha256; cv=none; b=goR0AQ3MJrvq+xvZiTf7ijsUUazKyzXi4E7+iHxTfoo2ITThOV9ZY067Gc0rOWio0xeIM3 Hogh7A433r9anwdQ2NTVGQS7+dy+mGBsPdZ+9jzvYCnmK2qU8nT2jd5B0VQ7Kmm2l/W2dr mgJJ/mq+dSJZdoeeruqHgBUZR0nWOU4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2C65360908; Sat, 4 May 2024 15:32:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 785E2C072AA; Sat, 4 May 2024 15:32:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1714836776; bh=W1KYPkox8fkNsg4FzwVivBA9xyKYIfqdEtzwYk7j8dg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TZ6mwWsdpO8tPgqajyyjyguNSqGMytj1NkC+qrcAA0JSWWpPfe2SpyL+TxXKbUtWF JPHxRWsmylBL2E0BpXufoXTL0XJqSE6sJkHN1GshLFgv4bRm5mghdHE1gouZE6ONR9 tFk2hgMi/F8dviXNhoSAXLir9gODlgYuhGxYEWGw= Date: Sat, 4 May 2024 17:32:53 +0200 From: Greg KH To: Andrii Nakryiko Cc: linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 5/5] selftests/bpf: a simple benchmark tool for /proc//maps APIs Message-ID: <2024050425-setting-enhance-3bcd@gregkh> References: <20240504003006.3303334-1-andrii@kernel.org> <20240504003006.3303334-6-andrii@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240504003006.3303334-6-andrii@kernel.org> X-Stat-Signature: a6ywgyo1grhutgi1nkh1c8kzw4y43i6j X-Rspamd-Queue-Id: DFD61120007 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1714836777-388097 X-HE-Meta: U2FsdGVkX18GZIROavrCUJhSliYeJN5nwXDN3YOsTCZZg4UZJbH0hoZhPO5HThhnsG38Le/MSU15GB3a2EzPYcTOb7Hd8JkBlkydtdLKonkluzvkDvGd2CSnvT9XvLUusj6p1v7vVciz1QtsYhJYOHWTdx6ko19JSYTe6J4xrTVo3AAaF9FgTf1Xgp89+Om/ttoOfHr47SJ00LAaPzn2R1TCzXP3Pbzra7fbk5PEe2Z+3Yjj4yuuCAtKonnqTdeUydCZN4TXEEXYACAfEguROZ6NXWGHG+rKtA99UCzA6/YNJsxuyEAqEO1W0Vn+ApIruSEeB10sC57qWhXrKDZ/aglPDPmMo3zUql+o9jZAml4Q5rK+dMcS2bXTm8N08zTksHSbLwZRx/GoRCE1fqsWJgpX2/fy+MUkYeoJ4ruPu/wI+jdXfGTxvA5Cd8m+jlOqnhhvu/Va8vt1DneP4nY3+fnNrZTzAaI1BKCGRN6ugnuapLQv1HsVsWOZtvRc0UyjabAsQ3dmct0qkilvUyxYhEWCmotr1CZ9XcfWHl94qJk1GVe/8axJBmcR4VfPFRNtT0jPIUX1njWzDKLlPZW5bo80TmQk/Us5e/bT/aMX53SaZLIGyUSlkfMlCWFUpwngHGa5+OpAd3/b1e02nmlzGhcownsI1x0FbJhtlQdzgsWC2SSNAeye3Nx/M9jQLoIwvAsaFgTBqe/XiGNaUDbVvnP0tFsWheuxcRFy5uBJm1JcPcliKMJX2U4OtTzi6hULQL72LoUppxMZ9QO8Ehz7sIjNLkm0Na0chnhkmy7d9YwD1JaTxhu+1QrQXTeulvdZKTAc8wQVcAr8XQY9LYMskfTCv8JE/jPcWlIvz9B921uVlgiUjs8dSyORNrEv3Eshc2msJZz2wHbrR6NE2Q7OLYSAY/PzBTJICFM6iFwBYt+OXsavx9BTqTu3D7wcfEtQKPyQo5KyyTQdvvoBtcT ch9eGJ21 5DeVujPeHjP+vqmJTp4XxLUaVtNX4louny/hKbK4a8IYuL68zyBDIFxXDLg/lFFttlpnCfPIAknISa47hci3DQvVj/9jZ0s2N1NoTyloMMq5mI/Gkj00ZiU9hei7vlcwPUHieSewrJb88nUoaJModIhERRJfSjznjO5SdzFRC3gyXQlae/Knk2Ny70g== 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: List-Subscribe: List-Unsubscribe: On Fri, May 03, 2024 at 05:30:06PM -0700, Andrii Nakryiko wrote: > I also did an strace run of both cases. In text-based one the tool did > 68 read() syscalls, fetching up to 4KB of data in one go. Why not fetch more at once? And I have a fun 'readfile()' syscall implementation around here that needs justification to get merged (I try so every other year or so) that can do the open/read/close loop in one call, with the buffer size set by userspace if you really are saying this is a "hot path" that needs that kind of speedup. But in the end, io_uring usually is the proper api for that instead, why not use that here instead of slow open/read/close if you care about speed? > In comparison, > ioctl-based implementation had to do only 6 ioctl() calls to fetch all > relevant VMAs. > > It is projected that savings from processing big production applications > would only widen the gap in favor of binary-based querying ioctl API, as > bigger applications will tend to have even more non-executable VMA > mappings relative to executable ones. Define "bigger applications" please. Is this some "large database company workload" type of thing, or something else? thanks, greg k-h