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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC3CCC433EF for ; Wed, 2 Feb 2022 16:54:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346030AbiBBQyG (ORCPT ); Wed, 2 Feb 2022 11:54:06 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:40508 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231706AbiBBQyE (ORCPT ); Wed, 2 Feb 2022 11:54:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643820843; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DPqXXCSvtXWPYnKF39SzZCno/APupEDKEIyaUUkXZKc=; b=NiJ/10STi4hnZiI3pRYqmgT2tilamIlD9Ri/LCgiyt7qp0KLAwh0k+DiERJ8+NJQt5U4U9 aVzeZxWxEI81zNcP0AJcS+2atObDwNVUVY1JdynBHoMPyCecRO1C2y4tHtPlX97IbciUsD mi9sZ0pIRb+JB9OhCIkhk5JTB9Y6Sno= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-127-QeDFCgTcO02K7x1KW0bJ2A-1; Wed, 02 Feb 2022 11:53:58 -0500 X-MC-Unique: QeDFCgTcO02K7x1KW0bJ2A-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BF45118C89CC; Wed, 2 Feb 2022 16:53:55 +0000 (UTC) Received: from [10.22.34.202] (unknown [10.22.34.202]) by smtp.corp.redhat.com (Postfix) with ESMTP id 05AF3753D0; Wed, 2 Feb 2022 16:53:52 +0000 (UTC) Message-ID: <4ba66abe-5c6d-26a7-f11c-c3b8514bfb34@redhat.com> Date: Wed, 2 Feb 2022 11:53:52 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v4 4/4] mm/page_owner: Record task command name Content-Language: en-US To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Ira Weiny , Mike Rapoport , David Rientjes , Roman Gushchin , Rafael Aquini , Vlastimil Babka References: <20220131192308.608837-5-longman@redhat.com> <20220131220328.622162-1-longman@redhat.com> From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/1/22 10:28, Michal Hocko wrote: > Cc Vlastimil > > On Mon 31-01-22 17:03:28, Waiman Long wrote: >> The page_owner information currently includes the pid of the calling >> task. That is useful as long as the task is still running. Otherwise, >> the number is meaningless. To have more information about the allocating >> tasks that had exited by the time the page_owner information is >> retrieved, we need to store the command name of the task. >> >> Add a new comm field into page_owner structure to store the command name >> and display it when the page_owner information is retrieved. > I completely agree that pid is effectivelly useless (if not misleading) > but is comm really telling all that much to compensate for the > additional storage required for _each_ page in the system? Yes, it does add an extra 16 bytes per page overhead. The command name can be useful if one want to find out which userspace command is responsible for a problematic page allocation. Maybe we can remove pid from page_owner to save 8 bytes as you also agree that this number is not that useful. Cheers, Longman