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=-7.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 8FFE5C433DF for ; Mon, 3 Aug 2020 15:46:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3AD0620781 for ; Mon, 3 Aug 2020 15:46:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3AD0620781 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CA5BD8D010C; Mon, 3 Aug 2020 11:46:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C30D08D0081; Mon, 3 Aug 2020 11:46:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1DB78D010C; Mon, 3 Aug 2020 11:46:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) by kanga.kvack.org (Postfix) with ESMTP id 97B2C8D0081 for ; Mon, 3 Aug 2020 11:46:09 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4F37E181AEF0B for ; Mon, 3 Aug 2020 15:46:09 +0000 (UTC) X-FDA: 77109683658.25.rose81_0b0edaa26f9e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 37A401804E501 for ; Mon, 3 Aug 2020 15:45:58 +0000 (UTC) X-HE-Tag: rose81_0b0edaa26f9e X-Filterd-Recvd-Size: 2718 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Mon, 3 Aug 2020 15:45:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id ADAECAB89; Mon, 3 Aug 2020 15:46:11 +0000 (UTC) Subject: Re: [PATCH] mm: sort freelist by rank number To: David Hildenbrand , pullip.cho@samsung.com, akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, hyesoo.yu@samsung.com, janghyuck.kim@samsung.com References: <1596435031-41837-1-git-send-email-pullip.cho@samsung.com> <5f41af0f-4593-3441-12f4-5b0f7e6999ac@redhat.com> From: Vlastimil Babka Message-ID: Date: Mon, 3 Aug 2020 17:45:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5f41af0f-4593-3441-12f4-5b0f7e6999ac@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 37A401804E501 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 8/3/20 9:57 AM, David Hildenbrand wrote: > On 03.08.20 08:10, pullip.cho@samsung.com wrote: >> From: Cho KyongHo >> >> LPDDR5 introduces rank switch delay. If three successive DRAM accesses >> happens and the first and the second ones access one rank and the last >> access happens on the other rank, the latency of the last access will >> be longer than the second one. >> To address this panelty, we can sort the freelist so that a specific >> rank is allocated prior to another rank. We expect the page allocator >> can allocate the pages from the same rank successively with this >> change. It will hopefully improves the proportion of the consecutive >> memory accesses to the same rank. > > This certainly needs performance numbers to justify ... and I am sorry, > "hopefully improves" is not a valid justification :) > > I can imagine that this works well initially, when there hasn't been a > lot of memory fragmentation going on. But quickly after your system is > under stress, I doubt this will be very useful. Proof me wrong. ;) Agreed. The implementation of __preferred_rank() seems to be very simple and optimistic. I think these systems could perhaps better behave as NUMA with (interleaved) nodes for each rank, then you immediately have all the mempolicies support etc to achieve what you need? Of course there's some cost as well, but not the costs of adding hacks to page allocator core?