Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
>


      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox