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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,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 AA600C433ED for ; Wed, 7 Apr 2021 12:15:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 26F3661042 for ; Wed, 7 Apr 2021 12:15:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 26F3661042 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8B96C6B007D; Wed, 7 Apr 2021 08:15:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 869B36B007E; Wed, 7 Apr 2021 08:15:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 732196B0080; Wed, 7 Apr 2021 08:15:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0201.hostedemail.com [216.40.44.201]) by kanga.kvack.org (Postfix) with ESMTP id 5A91F6B007D for ; Wed, 7 Apr 2021 08:15:06 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 164AD180AE7E1 for ; Wed, 7 Apr 2021 12:15:06 +0000 (UTC) X-FDA: 78005465412.02.0D7633A Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf21.hostedemail.com (Postfix) with ESMTP id 421B2E000111 for ; Wed, 7 Apr 2021 12:15:04 +0000 (UTC) Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4FFjv14sH4zPnlP; Wed, 7 Apr 2021 20:12:13 +0800 (CST) Received: from [10.174.176.73] (10.174.176.73) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.498.0; Wed, 7 Apr 2021 20:14:52 +0800 Subject: Re: [QUESTION] WARNNING after 3d8e2128f26a ("sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output") To: Matthew Wilcox , Greg KH , CC: , , , , , "zhangyi (F)" , Kefeng Wang , , "Zhengyejian (Zetta)" , Yang Yingliang , References: <5837f5d9-2235-3ac2-f3f2-712e6cf4da5c@huawei.com> <20210402144120.GO351017@casper.infradead.org> From: yangerkun Message-ID: <08b739b5-4401-e550-2028-1ce43db38141@huawei.com> Date: Wed, 7 Apr 2021 20:14:52 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20210402144120.GO351017@casper.infradead.org> Content-Type: text/plain; charset="gbk"; format=flowed X-Originating-IP: [10.174.176.73] X-CFilter-Loop: Reflected X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 421B2E000111 X-Stat-Signature: 7e7efnjn91ii8ftmna345of1kmypspkf Received-SPF: none (huawei.com>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=szxga05-in.huawei.com; client-ip=45.249.212.191 X-HE-DKIM-Result: none/none X-HE-Tag: 1617797704-224594 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: =D4=DA 2021/4/2 22:41, Matthew Wilcox =D0=B4=B5=C0: > On Fri, Apr 02, 2021 at 09:45:12AM +0200, Greg KH wrote: >> Why is the buffer alignment considered a "waste" here? If that change >> is in Linus's tree and newer kernels (it showed up in 5.4 which was >> released quite a while ago), where are the people complaining about it >> there? >> >> I think backporting 59bb47985c1d ("mm, sl[aou]b: guarantee natural >> alignment for kmalloc(power-of-two)") seems like the correct thing to = do >> here to bring things into alignment (pun intended) with newer kernels. >=20 > It's only a waste for slabs which need things like redzones (eg we coul= d > get 7 512-byte allocations out of a 4kB page with a 64 byte redzone > and no alignment ; with alignment we can only get four). Since slub > can enable/disable redzones on a per-slab basis, and redzones aren't > terribly interesting now that we have kasan/kfence, nobody really cares= . >=20 > . >=20 Thanks for your explain! The imfluence seems minimal since the "waste"=20 will happen only when we enable slub_debug. One more question for Joe Perches. Patch v2[1] does not add the alignment check for buf and we add it in v3[2]. I don't see the necessity for this check... Can you help to explain that why we need this= ? Thanks, Kun. [1].=20 https://lore.kernel.org/lkml/a9054fb521e65f2809671fa9c18e2453061e9d91.159= 8744610.git.joe@perches.com/ [2].=20 https://lore.kernel.org/lkml/743a648dc817cddd2e7046283c868f1c08742f29.cam= el@perches.com/