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 E28F6CA0EC3 for ; Tue, 12 Sep 2023 13:42:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7FB566B00F0; Tue, 12 Sep 2023 09:42:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AB416B00F1; Tue, 12 Sep 2023 09:42:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69A016B00F2; Tue, 12 Sep 2023 09:42:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 53D0B6B00F0 for ; Tue, 12 Sep 2023 09:42:44 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1A8DDC0269 for ; Tue, 12 Sep 2023 13:42:44 +0000 (UTC) X-FDA: 81228060648.22.FE83389 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 41CA4A0040 for ; Tue, 12 Sep 2023 13:42:42 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=L3DVia1W; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694526162; 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=+YST80+96+FKeOUG6Mux+YnG1fWt/FfWscMZ4ez6DB4=; b=Pk5eixunWzZQzbbYz5rvf59fnDmLy7zXFH0Dae43duzPbG061RUZPqDO3J9we1L11ZtcPO Y410ZQT69tw2u3DoS8e8wrVZIk4NLJwKhsEQayR1hgLrsdla/BP3VnfzpJaKdM/0Z72cuW a231ZWoS6ydHN2Teaum3eHwt/4HvsVg= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=L3DVia1W; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694526162; a=rsa-sha256; cv=none; b=TfAAcuNEVt0CcgY8xheJKTHX097NjdXaxFSDCBU9+mAY6ddIHJexJA9zYVCi7AJoLnozgx yYY7BDI5YYa+xUWxavEF42H+Me5IhVR6ghFreWTgjsz/m3gcSxtR2vnmKZxFF5flyqDDic vjpXuUaLNxW0drhpnLTNkzEbnOedbKY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694526161; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+YST80+96+FKeOUG6Mux+YnG1fWt/FfWscMZ4ez6DB4=; b=L3DVia1WQfASYeFu3etr1f1kT8OmEh6dNwygaFRzS6mmQKsh8zSUQ1u+o5NSjG86n8S/Zn Q0FDbL4Abo963AV7LBPA25VUbCogn02DlGd9pLAjtH0RriyjgAKvVjoDl5HLCq0VNKP4S1 j5gpGNJJuo+Fo0g6zTqiOCrcHp/JSyU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-538-fobPUqw1PdKY6DSFUOmluA-1; Tue, 12 Sep 2023 09:42:38 -0400 X-MC-Unique: fobPUqw1PdKY6DSFUOmluA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C2E8C101FAA3; Tue, 12 Sep 2023 13:42:37 +0000 (UTC) Received: from localhost (unknown [10.72.112.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 08A5410085C0; Tue, 12 Sep 2023 13:42:35 +0000 (UTC) Date: Tue, 12 Sep 2023 21:42:32 +0800 From: Baoquan He To: Uladzislau Rezki Cc: linux-mm@kvack.org, Andrew Morton , LKML , Lorenzo Stoakes , Christoph Hellwig , Matthew Wilcox , "Liam R . Howlett" , Dave Chinner , "Paul E . McKenney" , Joel Fernandes , Oleksiy Avramchenko Subject: Re: [PATCH v2 7/9] mm: vmalloc: Support multiple nodes in vread_iter Message-ID: References: <20230829081142.3619-1-urezki@gmail.com> <20230829081142.3619-8-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Rspamd-Queue-Id: 41CA4A0040 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: cb5kdjp5gdcsq8jrtxwmx7druxjot7t3 X-HE-Tag: 1694526162-169184 X-HE-Meta: U2FsdGVkX1/mA4NjaCNCFQRtgLBV9l4AHE8HeRrZ7OMZpDdxb4i8myxWEC+2tVcfHNBKnSChMe37Jl5UmfoDSydR3AvNH7HoGX7EA1QGXBgcFIVKvPv0yOeS69LkI1jJ9psKLw9st5XxZXH0F8M2Vw0tkWEP9ra8RJyYI6PXaBHnwuaBjvogWHLDatnzDPf7Qv3DNtip35kbOtbq+malt4JmfXHvat01FOyKg3hoCiySv/M7CCT3UTOtFzze/0uhiEVvop7CasxY6ohGm6Fld/AkvFHj04Vl82qyUmpRGMRd5sgaZ0qvYBJpxttTBOSFKluxMwzTeiJR763jFIN/TOiZ/lQVaWDQB7raJZQKu2S2JhaiQ2vX47X12QQftPimU87gYCQG3FEvnZ8+EOv95QcwLQivDBR6sSkB1hfZEwhUazHr9s/Y3X+nTFFFVGDK6qS8bxS8CA0tDQwh+1Pvj+cvFWrLys6TvA3+c6hiWQMO8MB9VW/ES+w9k37Zu7LQEljhzxxBYH8naN1hsK2H+bepPIeYBzTBXWxbZoCqcZ/SCoC3wHGDkBMXr2HTjLCIXXG97xOeSf+a3CtY3IGd/NyBn4/2Le9Hiu38rYUcuUzf82Zf7rmVY8QEmy9cXx4N+/WF2QMqXmg2hpwp+k9FeKlKAIttomOgKq8uSUxJTFbg3matX5TmKasJdrXzVxCN+wsRe7QoATC7hliVxjjLJ4gQn9LX3GO/+suyfM3t0VxYIygpZDHcf8+7ffSM22CXk+8DHsVNWeYMzLdItIxd1E1lJHU8nDrCQIq+YC9KNp2zEnJt0Ozn0DfHu+EjSCrl5IfpfKDUorRy2fngkbhJ0jJXlhS9gwLY9Q4lmMyGvQsXGxwUvHuzUR9En4Boq1fWp46FNvF6I8iK9hlPigvgnbBe0DPIwDJq3VTYUtrZgxg66Ps0vqA1tqnX65YFFIv5HUSp/k6EU8PjXYriPz0 +RbHesmX KNbkUXurZoibq0shDHSdSF3b65oX6AUfqzGEqL7J9n8sRZtbZItVJlHhwBVkd1krKaDNQq1tzXXjEpvxtwX8gqgZfgUJxSRTjlRrkd+ZOwssQg8l2Li84Ee+wv6H9YMgj2MER9+P3R52bWq69N+F2IwSBDenSPZ8rMJn6z9tQy7V7HdKrXz28ubvVzhqjyMXvm5byEE3Pn8PV8KksDZvEYmGYZZ1RtxQNAfJmn7SCozJ4iV5FUZwJGPm00G/9a1UapahMx19oi2d0d5sd53e2X0Ia2Q== 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: On 09/11/23 at 08:16pm, Uladzislau Rezki wrote: > On Mon, Sep 11, 2023 at 11:58:13AM +0800, Baoquan He wrote: > > On 08/29/23 at 10:11am, Uladzislau Rezki (Sony) wrote: > > > Extend the vread_iter() to be able to perform a sequential > > > reading of VAs which are spread among multiple nodes. So a > > > data read over the /dev/kmem correctly reflects a vmalloc > > > memory layout. > > > > > > Signed-off-by: Uladzislau Rezki (Sony) > > > --- > > > mm/vmalloc.c | 67 +++++++++++++++++++++++++++++++++++++++++----------- > > > 1 file changed, 53 insertions(+), 14 deletions(-) > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > > index 4fd4915c532d..968144c16237 100644 > > > --- a/mm/vmalloc.c > > > +++ b/mm/vmalloc.c > > ...... > > > @@ -4057,19 +4093,15 @@ long vread_iter(struct iov_iter *iter, const char *addr, size_t count) > > > > > > remains = count; > > > > > > - /* Hooked to node_0 so far. */ > > > - vn = addr_to_node(0); > > > - spin_lock(&vn->busy.lock); > > > > This could change the vread behaviour a little bit. Before, once we take > > vmap_area_lock, the vread will read out the content of snapshot at the > > moment. Now, reading out in one node's tree won't disrupt other nodes' > > tree accessing. Not sure if this matters when people need access > > /proc/kcore, e.g dynamic debugging. > > > With one big tree you anyway drop the lock after one cycle of reading. > As far as i see, kcore.c's read granularity is a PAGE_SIZE. With my understanding, kcore reading on vmalloc does read page by page, it will continue after one page reading if the required size is bigger than one page. Please see aligned_vread_iter() code. During the complete process, vmap_area_lock is held before this patch. > > > > > And, the reading will be a little slower because each va finding need > > iterate all vmap_nodes[]. > > > Right. It is a bit tough here, because we have multiple nodes which > represent zones(address space), i.e. there is an offset between them, > it means that, reading fully one tree, will not provide a sequential > reading. Understood. Suppose the kcore reading on vmalloc is not critical. If I get chance to test on a machine with 256 cpu, I will report here.