lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Oct 2020 11:18:39 +0200 From: David Hildenbrand <david@...hat.com> To: Wei Yang <richard.weiyang@...ux.alibaba.com> Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, virtualization@...ts.linux-foundation.org, Andrew Morton <akpm@...ux-foundation.org>, "Michael S . Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>, Pankaj Gupta <pankaj.gupta.linux@...il.com> Subject: Re: [PATCH v1 09/29] virtio-mem: don't always trigger the workqueue when offlining memory On 16.10.20 06:03, Wei Yang wrote: > On Mon, Oct 12, 2020 at 02:53:03PM +0200, David Hildenbrand wrote: >> Let's trigger from offlining code when we're not allowed to touch online >> memory. > > This describes the change in virtio_mem_memory_notifier_cb()? Ah, yes, can try to make that clearer. > >> >> Handle the other case (memmap possibly freeing up another memory block) >> when actually removing memory. When removing via virtio_mem_remove(), >> virtio_mem_retry() is a NOP and safe to use. >> >> While at it, move retry handling when offlining out of >> virtio_mem_notify_offline(), to share it with Device Block Mode (DBM) >> soon. > > I may not understand the logic fully. Here is my understanding of current > logic: > > > virtio_mem_run_wq() > virtio_mem_unplug_request() > virtio_mem_mb_unplug_any_sb_offline() > virtio_mem_mb_remove() --- 1 > virtio_mem_mb_unplug_any_sb_online() > virtio_mem_mb_offline_and_remove() --- 2 > > This patch tries to trigger the wq at 1 and 2. And these two functions are > only valid during this code flow. Exactly. > > These two functions actually remove some memory from the system. So I am not > sure where extra unplug-able memory comes from. I guess those memory is from > memory block device and mem_sectioin, memmap? While those memory is still > marked as online, right? Imagine you end up (only after some repeating plugging and unplugging of memory, otherwise it's obviously impossible): Memory block X: Contains only movable data Memory block X + 1: Contains memmap of Memory block X: We start to unplug from high, to low. 1. Try to unplug/offline/remove block X + 1: fails, because of the memmap 2. Try to unplug/offline/remove block X: succeeds. 3. Not all requested memory got unplugged. Sleep for 30 seconds. 4. Retry to unplug/offline/remove block X + 1: succeeds What we do in 2, is that we trigger a retry of ourselves. That means, that in 3. we don't actually sleep, but retry immediately. This has been proven helpful in some of my tests, where you want to unplug *a lot* of memory again, not just some parts. Triggering a retry is fairly cheap. Assume you don't actually have to perform any more unplugging. The workqueue wakes up, detects that nothing is to do, and goes back to sleep. -- Thanks, David / dhildenb
Powered by blists - more mailing lists