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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 8BB58C43460 for ; Tue, 27 Apr 2021 12:46:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2B26F613C0 for ; Tue, 27 Apr 2021 12:46:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B26F613C0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 970826B0036; Tue, 27 Apr 2021 08:46:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 946076B006E; Tue, 27 Apr 2021 08:46:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 798F26B0070; Tue, 27 Apr 2021 08:46:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id 5E3D06B0036 for ; Tue, 27 Apr 2021 08:46:14 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 164E43636 for ; Tue, 27 Apr 2021 12:46:14 +0000 (UTC) X-FDA: 78078119868.17.4715862 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf05.hostedemail.com (Postfix) with ESMTP id 8B837E00012C for ; Tue, 27 Apr 2021 12:46:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619527573; 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=Hksqsg/+fYJgnfwVftoEYR0ZtkMbPnUNSSTSXlz+2vM=; b=UnzhZ1H+2KPKesD2JMOrgSP54uwmVhoAv9G8JX6G6c9B54oP/8/T8XFFcU72XBwK2HHzsX 9gidBweM5ItIY53deIrO7pbCqto1Yn5sJ6WXdgRXyQRd67m72zPcWGmxNLflFsEDFgyoT4 MXsxTw5R0pmH6D2+Aph4kWXGOJC7x2M= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-590-oL3jN7iIPl-OE_MC7Pea1Q-1; Tue, 27 Apr 2021 08:46:09 -0400 X-MC-Unique: oL3jN7iIPl-OE_MC7Pea1Q-1 Received: by mail-wm1-f69.google.com with SMTP id y184-20020a1ce1c10000b0290143299f39d7so785398wmg.4 for ; Tue, 27 Apr 2021 05:46:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Hksqsg/+fYJgnfwVftoEYR0ZtkMbPnUNSSTSXlz+2vM=; b=fejM8gZ3z+Zf5DDbZ1yo7gDAZl8GV8lK3uVG6BhU0Bgf0/6GOYW/C+8C2e5YxsvHwG sWrm7p0DmBvrZHi/1wWPhU9CATc3ps+Yprl3VGKveUIoHg/H9lS56ycBUnFokX+VFCl2 OApQsI4Wc74wWW6NqlhtL8Yh17LQSgMP0ro+NMgyJ9BIrwPBoTyBpvPDKQWuMdZKklFs 4KeChNuUFuncRO/tb8gGNCmQSLDsVpSqu8M+NYOfaqkvd7w5Au9K5RXOTRqmyZcoMjwA ZTFAANh1pQCx0DK3JpTMuf1HQhE/lBxVJ+MW1CdH9c7p1cjnYEHh8wXGojA3SukniaG2 M8Pg== X-Gm-Message-State: AOAM530e2t94FWtw3wzBjKmKaPqB5ZJECtlW+Z+/JR3Ef4JDSBReHltw 2aYnWO+IygmP/jJ1bZS2Nw0iqNQChgU+lhcNO88iOAP1vGOOVabW4LDknUVFXcRHvsznSXRgxEM FWTK8WJXMY14i62hMUITcCjZMGdWW+PyRjCj7We4/FH+nCTN6lRoKt4Adk2Y= X-Received: by 2002:a5d:4cc1:: with SMTP id c1mr29737365wrt.291.1619527567788; Tue, 27 Apr 2021 05:46:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXAByV9LoODF4QKZww/QfS7aasYO7weAeY5ZC9MriJsvGwv3uvieCWGjXfIy5U9hskI4MSNg== X-Received: by 2002:a5d:4cc1:: with SMTP id c1mr29737320wrt.291.1619527567408; Tue, 27 Apr 2021 05:46:07 -0700 (PDT) Received: from ?IPv6:2003:d8:2f38:2400:62f4:c5fa:ba13:ac32? (p200300d82f38240062f4c5faba13ac32.dip0.t-ipconnect.de. [2003:d8:2f38:2400:62f4:c5fa:ba13:ac32]) by smtp.gmail.com with ESMTPSA id g5sm3841603wrq.30.2021.04.27.05.46.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Apr 2021 05:46:06 -0700 (PDT) To: "lipeifeng@oppo.com" , Vlastimil Babka , peifengl55 , schwidefsky , "heiko.carstens" , zhangshiming , zhouhuacai , guoweichao , guojian Cc: linux-s390 , linux-kernel , linux-mm References: <20210414023803.937-1-lipeifeng@oppo.com> <2021042611194631963076@oppo.com> <7dcc87f5-9ae5-613a-0cf4-820334592b90@redhat.com> <20210426181947189100132@oppo.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC] mm: support multi_freearea to the reduction of external fragmentation Message-ID: <9808e36a-9e4e-d1e2-da49-beb567681a8b@redhat.com> Date: Tue, 27 Apr 2021 14:46:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210426181947189100132@oppo.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 8B837E00012C X-Stat-Signature: masiymed6g4okqq61ego7oc591iebp8w Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf05; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619527571-471673 Content-Transfer-Encoding: quoted-printable 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 26.04.21 12:19, lipeifeng@oppo.com wrote: > Hi David Hildenbrand =EF=BC=9A >=20 > >> And you don't mention what the baseline configuration was. For exam= ple, > >> how was compaction configured? > >> Just to clarify, what is monkey? > >> Monkey HTTP server? MonkeyTest disk benchmark? UI/Application Exerc= iser > >> Monkey? > -----------------------------------------------------------------------= -------------- > I am sorry that i didn't=C2=A0=C2=A0give a clear explanation about Monk= ey. > It meant=C2=A0 "UI/Application Exerciser Monkey" from google. >=20 > Excuse me, let me introduce our test: >=20 Thanks for more details on the test. > 1. record COMPACT_STALL > We tested the patch on linux-4.4/linux-4.9/linux-4.14/linux-4.19 and th= e > results shows that the patch is effective in reducing COMPACTSTALL. > =C2=A0 =C2=A0 - monkey for 12 hours. > =C2=A0 =C2=A0 - record COMPACTSTALL after test. >=20 > Test-result: reduced COMPACTSTALL by 95.6% with the patch. > (the machine with 4 gigabytes of physical memery and in linux-4.19.) > --------------------------------- > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 COMPACTSTA= LL > --------------------------------- > =C2=A0=C2=A0 ori =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0=C2=A0=C2=A0 2189 > --------------------------------- > optimization |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 95 > --------------------------------- >=20 > I fully agree with the value of compaction, but compaction also bring c= pu > consumption and will increase the time of alloc_stall. So if we can let= more > free high-orders-pages in buddy instead of signal pages, it will decrea= se > COMPACT_STALL and speed up memory allocation. Okay, but then I assume the target goal of your patch set is to minimize=20 CPU consumption/allocation stall time when allocating larger order pages. Currently you state "the probablity of high-order-pages allocation would=20 be increased significantly", but I assume that's then not 100% correct.=20 What you measure is the stall time to allocate higher order pages, not=20 that you can allocate them. >=20 > 2. record the speed of the high-orders-pages allocation(order=3D4 and=20 > order =3D 8) > Before and after optimization, we tested the speed of the=20 > high-orders-pages allocation > after 120-hours-Monkey in 10 Android mobile phones. and the result show= that > the speed has been=C2=A0increased by more than 18%. >=20 > Also, we do some test designed by us: > (the machine with 4 gigabytes of physical memery and in linux-4.19.) > model the usage of users, and constantly start and > operate the diffrent application for 120h, and we record COMPACT_STALL=20 > is decreased by > 90+% and speed of the high-orders-pages is increaed by 15+%. Okay, again, this is then some optimization for allocation speed; which=20 makes it less attractive IMHO (at least for more invasive changes),=20 because I suspect this mostly helps in corner cases (Monkey benchmarks=20 corner cases AFAIU). >=20 > and I have some question, i hope you can guide me if when you are free. > 1) What is the compaction configured? > =C2=A0 =C2=A0 Dost it meant the members in zone? like as follows: > =C2=A0 =C2=A0 unsigned int compact_considered; > =C2=A0 =C2=A0 unsigned int compact_defer_shift; > =C2=A0 =C2=A0 int compact_order_failed; > =C2=A0 =C2=A0 bool compact_blockskip_failed; > =C2=A0 =C2=A0 Or the some Macro variable? like as follows: > =C2=A0 =C2=A0 PAGE_ALLOC_COSTLY_ORDER =3D 3 > =C2=A0 =C2=A0 MIN_COMPACT_PRIORITY =3D 1 > =C2=A0 =C2=A0 MAX_COMPACT_RETRIES =3D 16 >=20 Rather if you have proactive compaction=20 (/proc/sys/vm/compaction_proactiveness). But I assume because you're=20 messing with older kernels, that you didn't compare against that yet.=20 Would be worth a comparison. >>> 1) multi freearea (which might > >> be problematic with sparcity) > 2) Can you pls tell me what is soarcity and what is the impact of this? > =C2=A0 =C2=A0 and whether there are some documents about it? Essentially CONFIG_SPARSEMEM, whereby we can have huge holes in physical=20 memory layout and memory areas coming/going with memory hot(un)plug.=20 Usually we manage all metadata per section. For example, pageblocks are=20 allocated per section. We avoid arrays that depend on the=20 initial/maximum physical memory size. --=20 Thanks, David / dhildenb