From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: [ANNOUNCE/CFP] LPC 2026 Kernel Memory Management Microconference (reminder)
Date: Mon, 20 Jul 2026 14:03:50 +0100 [thread overview]
Message-ID: <al4HTMtzpDHykhbI@lucifer> (raw)
In-Reply-To: <e3dc73df-0032-4e71-ab80-21b29c6efb46@kernel.org>
Just a reminder for everybody to send their proposals in before the deadline on
July 24th! :)
See below for guidelines.
Cheers, Lorenzo
On Mon, May 18, 2026 at 11:26:21PM +0200, David Hildenbrand (Arm) wrote:
> Hi,
>
> We are happy to announce yet another instance of the
>
> Kernel Memory Management Microconference [1]
>
> Co-lead by Lorenzo Stoakes and myself at the Linux Plumbers Conference
> (LPC), October 5-7, Prague, Czechia [2].
>
> Due to our past experience with remote presentations, we will only
> accept in-person talks, unfortunately.
>
> We are looking for topics that would be of interest to the kernel
> memory-management community.
>
> We are also interested in topic suggestion from outside the core kernel
> community - if you have something interesting to present related to memory
> management in userspace, driver code, architectural code or anywhere else that
> touches kernel memory management we'd love to hear from you!
>
> Examples of topics that might be worth discussing this year include:
>
> * Making (m)THP/large folios first-class citizens
> * Supporting gigabyte THPs: allocators, compaction, policies
> * Better policies: applying eBPF and friends sensibly in MM
> * Polishing memory reclaim: making MGLRU less special
> * Ongoing challenges with memdescs conversion
> * Can we make device memory less special?
> * Letting the kernel manage special-purpose memory
> * Improving page promotion/demotion for memory tiering
> * Challenges with hypervisor live-update integration
> * Towards deprecating hugetlb: mshare, memory reserves
> * The future of swap: missing pieces, cleanups, and do we still need zram?
> * The future of memcg: new resources, optimizations, and cleanups
> * Doing more with less memory (RAM is getting expensive ...)
>
> Please submit your proposals at:
>
> https://lpc.events/event/20/abstracts/
>
> and select "Kernel Memory Management MC" as the track.
>
> Please submit your proposals by July 24th to give us time to schedule talks in
> advance of the conference.
>
> We greatly value interaction - talks are meant to be dialogues between the
> speaker and the audience. Therefore, plan to leave AT LEAST 1/3 of your slot
> (likely 30min, tbd) open for discussion. We intend to be strict about enforcing
> this :)
>
> Please ensure your slides aren't too dense - people take away more when you use
> fewer words, and that also helps the discussion!
>
> We are looking forward to your proposals and seeing you in Prague!
>
>
> Note: make sure to register early, ideally before the announcement of topics.
> Usually the conference organizers ensure that all speakers are able to
> register, but the conference is very popular and it's been a close run thing in
> the past, so registering early is the safest option.
>
> [1] https://lpc.events/event/20/contributions/2337/
> [2] https://lpc.events/
>
> --
> Cheers,
>
> David
>
prev parent reply other threads:[~2026-07-20 13:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 21:26 [ANNOUNCE/CFP] LPC 2026 Kernel Memory Management Microconference David Hildenbrand (Arm)
2026-07-20 13:03 ` Lorenzo Stoakes (ARM) [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=al4HTMtzpDHykhbI@lucifer \
--to=ljs@kernel.org \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.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.