All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Song Liu <song@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: bpf@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, ast@kernel.org,
	daniel@iogearbox.net, kernel-team@fb.com,
	akpm@linux-foundation.org, rick.p.edgecombe@intel.com,
	hch@infradead.org, imbrenda@linux.ibm.com
Subject: Re: [PATCH bpf 0/4] bpf_prog_pack and vmalloc-on-huge-page fixes
Date: Fri, 22 Apr 2022 07:42:32 -0700	[thread overview]
Message-ID: <YmK+2AyIuqaySkHQ@bombadil.infradead.org> (raw)
In-Reply-To: <20220422051813.1989257-1-song@kernel.org>

On Thu, Apr 21, 2022 at 10:18:09PM -0700, Song Liu wrote:
> NOTE: This set is based on Linus' master branch (d569e86915b7), not
> bpf/master.
> 
> There are various discussion about these changes, check out [1] [2].
> I guess we can use this thread to discuss which patches should go in 5.18.
> AFAICT, 1/4 need to with 5.18;

Since huge pages are effectively disabled on v5.18 I can't see why.

> 2/4 seems safe to go as well;

My impression on the discussion was that huge pages design was broken
and evidence for this came up after x86 finally enabled *a small*
portion use case of it. This revealed how broken huge pages were not
just for x86 but for other architectures. And so I can't see why we'd
enable for v5.18 huge pages for the large system hash.

> 3/4 and 4/4
> may still need more work/discussion.

Happy to review these but if huge pages are disabled I don't see the
point in a module_alloc_huge() yet.

  Luis

> 
> Thanks!
> 
> [1] https://lore.kernel.org/linux-mm/20220415164413.2727220-1-song@kernel.org/
> [2] https://lore.kernel.org/linux-mm/20220421072212.608884-1-song@kernel.org/
> 
> Song Liu (4):
>   bpf: invalidate unused part of bpf_prog_pack
>   page_alloc: use vmalloc_huge for large system hash
>   module: introduce module_alloc_huge
>   bpf: use module_alloc_huge for bpf_prog_pack
> 
>  arch/x86/kernel/module.c     | 21 +++++++++++++++++++++
>  arch/x86/net/bpf_jit_comp.c  | 22 ++++++++++++++++++++++
>  include/linux/bpf.h          |  2 ++
>  include/linux/moduleloader.h |  5 +++++
>  kernel/bpf/core.c            | 28 +++++++++++++++++++++-------
>  kernel/module.c              |  8 ++++++++
>  mm/page_alloc.c              |  2 +-
>  7 files changed, 80 insertions(+), 8 deletions(-)
> 
> --
> 2.30.2

      parent reply	other threads:[~2022-04-22 14:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22  5:18 [PATCH bpf 0/4] bpf_prog_pack and vmalloc-on-huge-page fixes Song Liu
2022-04-22  5:18 ` [PATCH bpf 1/4] bpf: invalidate unused part of bpf_prog_pack Song Liu
2022-04-22  5:18 ` [PATCH bpf 2/4] page_alloc: use vmalloc_huge for large system hash Song Liu
2022-04-22  9:06   ` kernel test robot
2022-04-22  5:18 ` [PATCH bpf 3/4] module: introduce module_alloc_huge Song Liu
2022-04-22  9:48   ` kernel test robot
2022-04-22  5:18 ` [PATCH bpf 4/4] bpf: use module_alloc_huge for bpf_prog_pack Song Liu
2022-04-22 14:42 ` Luis Chamberlain [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmK+2AyIuqaySkHQ@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hch@infradead.org \
    --cc=imbrenda@linux.ibm.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=song@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.