Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Song Liu <songliubraving@fb.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
CC:     bpf <bpf@vger.kernel.org>, Networking <netdev@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrii Nakryiko <andrii@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Kernel Team <Kernel-team@fb.com>,
        Christoph Hellwig <hch@infradead.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Song Liu <song@kernel.org>
Subject: Re: [PATCH bpf v2 0/3] bpf: invalidate unused part of bpf_prog_pack
Thread-Topic: [PATCH bpf v2 0/3] bpf: invalidate unused part of bpf_prog_pack
Thread-Index: AQHYWOUphDgBQzjiX0ac6c+Sg/0OBq0EVWkAgAA8D4CAAFTGAIAOJWIA
Date:   Sat, 7 May 2022 06:50:17 +0000
Message-ID: <719D99A4-3100-49EC-A7D6-6F9CDBA053C4@fb.com>
References: <20220425203947.3311308-1-song@kernel.org>
 <FF2E0EC1-F9D6-4196-8887-919207BDC599@fb.com>
 <CAHk-=wgA1Uku=ejwknv11ssNhz2pswhD=mJFBPEMQtCspz0YEQ@mail.gmail.com>
 <57DBEBDB-71AF-4A85-AB8D-8274541E0F3C@fb.com>
In-Reply-To: <57DBEBDB-71AF-4A85-AB8D-8274541E0F3C@fb.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?BX6ck53NmvO4D/7Xp2vkc0IF7Yx3lWYox0FQBBrOptEsrMBKljJyF2b+9ZNW?=
 =?us-ascii?Q?xiLh7T5bC+odZGfRNE5eyKQAmvFmb83q8OtzXWYv4CJp/D3O5pVbkeUA++56?=
 =?us-ascii?Q?gg485WC57m3dWa85dunsFLe2yDIg2ascAiKr/OUadjqMzg10rz1XoH3WFsqs?=
 =?us-ascii?Q?5lg1yzktj+oMIK1Aekmhi3RcncrVUnWXAO9ED/Er88jzrEOCT/vzkPT4Ahmo?=
 =?us-ascii?Q?TfgdWvGHt42wMWc/0F4szAqs+KcJoyTuTibq+gGCWeOnwBIif31NAabKurmd?=
 =?us-ascii?Q?rFVZTC1ELaR9j8DhtsbihGlwsddsp0oqUN9OidqIwaLhNG6rugxmywGJghdQ?=
 =?us-ascii?Q?SWkU+NuNYtjmBpQ6tXSpzD9xHf5CySip3fNF0X16QQ1IVhJVfCRnExV9q5Zm?=
 =?us-ascii?Q?kGRiEK+Q8UZodPGjTsK6I7/OC8aHxUCY1mD+mEveH/lTjV8ZIMnvAPIL5C64?=
 =?us-ascii?Q?EbfplIgTqJdeNcKhLfb0PWMuhFXTM1BKITU2QP145ul83GvLPbC93u9Wan4T?=
 =?us-ascii?Q?9m+1hFOaotu9VYbyPjAWKvXNv48BeuEOLmrmc3izzy8SLx8XsR75WIt+pVOd?=
 =?us-ascii?Q?frpaKDZS/hWKQbDpfBnxojxi5Hyxwh1UribXQqsvwnw1u2aiS5l/Y6ksVs8L?=
 =?us-ascii?Q?T2k7GVZS7v2cUUAy+HGQJnvUSF8Vqg96H4xMva6pa5IJg7943nyw9N5IFB/H?=
 =?us-ascii?Q?XS0zmSxQwS7LqzQWZd1y6e8smjSH9xSmK6yxxaD8zxpTSMKY+WOrzrVidNkb?=
 =?us-ascii?Q?MhqKOGL3+E85Q5jTIfTzR0CFUX2R34iHP1PuFBTICQZNwFs526OSxHElTNg4?=
 =?us-ascii?Q?5k2jVC53F2gv3OKvRIC5jnIr9OMYYvPh9bHDHcmIAr0Ff/xtsm1wXY10hUlG?=
 =?us-ascii?Q?TVV8Er/QIkhm1udjzs/jVt36i71ojeknbq13l5VReNo1KGIxNvIOonCUOnyx?=
 =?us-ascii?Q?zey+vifn7W+8y6MVKi6x/Jc0EhEm9USKe+wtR927dZL6F39BbdK/TZvv8MqJ?=
 =?us-ascii?Q?7lcUrYpUCSuxRBeszOrJntVekDtKfkb1m8ZVsXnO9C2o5cxOYO9YhOk58aCR?=
 =?us-ascii?Q?EmK6g4hrwEuaE6j+gFfKAW21O9HJFhsbcgqQBKdU8/jCVuweZrpo1LC7GhiA?=
 =?us-ascii?Q?myVcVqLaGr1jkAPRDfLQB5OvukQiz1wo7uIuBBKDPCKLW63F1ivBgkTs8jLO?=
 =?us-ascii?Q?whfHKImUI8VEToxUL/PleFm+6u6u0hkiS1/o1ybEMEoiU35pxvGQh/xjv9ni?=
 =?us-ascii?Q?qsVf2GaqMdMwHgrYuKHlE6dajdnTRtA5tCpZL/5PALcgZZkJahypXVejr21I?=
 =?us-ascii?Q?Z0xQdEtnV8ZD2OhjbWbHSTElZuAKwbrBAyOs/85zs+zYPnIVokZKkq7H1wfA?=
 =?us-ascii?Q?6a2Waj7LdTilgTwCtkwkPkiqy21/3KbJYAxExyFv0/IASJF23d1h1lDevUG6?=
 =?us-ascii?Q?czaHaBzxbYvVCqIPLVXxTIPe/twUNcFHSDCxC9rTMKB8W7rC3hOMybFIhxdu?=
 =?us-ascii?Q?worlnc0T5nVzg+qSwlWX1Y+FsEBBURp6KnVnsEa/VLg+CFO0PqDg3Snx/ubw?=
 =?us-ascii?Q?TLjoh6a1GwZAEIYcPkCP0vOBkHV4qP1SWz27P2QZRIqilNNhOy/2OFiw2Emb?=
 =?us-ascii?Q?rKXjxe28fCsQFh/1qogQ0vM46DzE6WZ6TLyNLLlXuoLZZKIP7fD5YWSsgWyn?=
 =?us-ascii?Q?x3JNnnyk8WqlWKCOC8UrujdGzyKLERnT0VFxw/bZssMJ6AjsNLXB8ejhknv+?=
 =?us-ascii?Q?33vo1cfiChJYYY2hb/HMKJoQo97v/qvUqOVaGitqngpNzbx3aVbz?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B7E9BE8D5516A4489D391CE62989F01F@namprd15.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: fb.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR15MB5109.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 48dfa491-a105-45b4-b8c9-08da2ff5d8c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2022 06:50:17.6232
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: W7EEBmEBBeWJbSyPqANjN/BQOC98mNjYvyDAc3aT5NhoECdg+bAjm3y5Cj5gE6EwHFId9FN3LzQpSbPMO3mPnw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR15MB3899
X-Proofpoint-GUID: 6-uOja5wENfFAKWzwNgajp_jERFDQnU7
X-Proofpoint-ORIG-GUID: 6-uOja5wENfFAKWzwNgajp_jERFDQnU7
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514
 definitions=2022-05-07_01,2022-05-06_01,2022-02-23_01
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Apr 27, 2022, at 11:48 PM, Song Liu <songliubraving@fb.com> wrote:
> 
> Hi Linus, 
> 
> Thanks for your thorough analysis of the situation, which make a lot of
> sense. 
> 
>> On Apr 27, 2022, at 6:45 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> 
>> On Wed, Apr 27, 2022 at 3:24 PM Song Liu <songliubraving@fb.com> wrote:
>>> 
>>> Could you please share your suggestions on this set? Shall we ship it
>>> with 5.18?
>> 
>> I'd personally prefer to just not do the prog_pack thing at all, since
>> I don't think it was actually in a "ready to ship" state for this
>> merge window, and the hugepage mapping protection games I'm still
>> leery of.
>> 
>> Yes, the hugepage protection things probably do work from what I saw
>> when I looked through them, but that x86 vmalloc hugepage code was
>> really designed for another use (non-refcounted device pages), so the
>> fact that it all actually seems surprisingly ok certainly wasn't
>> because the code was designed to do that new case.
>> 
>> Does the prog_pack thing work with small pages?
>> 
>> Yes. But that wasn't what it was designed for or its selling point, so
>> it all is a bit suspect to me.
> 
> prog_pack on small pages can also reduce the direct map fragmentation.
> This is because libbpf uses tiny BPF programs to probe kernel features. 
> Before prog_pack, all these BPF programs can fragment the direct map.
> For example, runqslower (tools/bpf/runqslower/) loads total 7 BPF programs 
> (3 actual programs and 4 tiny probe programs). All these programs may 
> cause direct map fragmentation. With prog_pack, OTOH, these BPF programs 
> would fit in a single page (or even share pages with other tools). 

Here are some performance data from our web service production benchmark, 
which is the biggest service in our fleet. We compare 3 kernels:    

  nopack: no bpf_prog_pack; IOW, the same behavior as 5.17
  4kpack: use bpf_prog_pack on 4kB pages (same as 5.18-rc5)
  2mpack: use bpf_prog_pack on 2MB pages

The benchmark measures system throughput under latency constraints. 
4kpack provides 0.5% to 0.7% more throughput than nopack. 
2mpack provides 0.6% to 0.9% more throughput than nopack. 

So the data has confirmed:
1. Direct map fragmentation has non-trivial impact on system performance;
2. While 2MB pages are preferred, bpf_prog_pack on 4kB pages also gives 
   Significant performance improvements.  

Thanks,
Song