This might have fallen through the cracks. Any opinions?
On Fri, Nov 13, 2020 at 6:26 PM Alexander Potapenko wrote:
>
> Hi Amos, Rusty, Amit, Michael,
>
> I am hitting something that I believe to be a minor problem in the
> virtio RNG driver.
> When running the kernel under KMSAN with "-device
Currently, the "auto-movable" online policy does not allow for hotplugged
KERNEL (ZONE_NORMAL) memory to increase the amount of MOVABLE memory we can
have, primarily, because there is no coordiantion across memory devices and
we don't want to create zone-imbalances accidentially when unplugging
Use memory groups to improve our "auto-movable" onlining policy:
1. For static memory groups (e.g., a DIMM), online a memory block MOVABLE
only if all other memory blocks in the group are either MOVABLE or could
be onlined MOVABLE. A DIMM will either be MOVABLE or not, not a mixture.
2.
Let's use a single dynamic memory group.
Signed-off-by: David Hildenbrand
---
drivers/virtio/virtio_mem.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 774986695dc4..19036922f7ef 100644
Although dax/kmem users often disable auto-onlining and instead online
memory manually (usually to ZONE_MOVABLE), there is still value in
having auto-onlining be aware of the relationship of memory blocks.
Let's treat one probed unit as a single static memory device, similar to
a single ACPI
Let's group all memory we add for a single memory device - we want a
single node for that (which also seems to be the sane thing to do).
We won't care for now about memory that was already added to the system
(e.g., via e820) -- usually *all* memory of a memory device was already
added and we'll
Let's track all present pages in each memory group. Especially, track
memory present in ZONE_MOVABLE and memory present in one of the kernel
zones (which really only is ZONE_NORMAL right now as memory groups only
apply to hotplugged memory) separately within a memory group, to prepare
for making
In our "auto-movable" memory onlining policy, we want to make decisions
across memory blocks of a single memory device. Examples of memory devices
include ACPI memory devices (in the simplest case a single DIMM) and
virtio-mem. For now, we don't have a connection between a single memory
block
When onlining without specifying a zone (using "online" instead of
"online_kernel" or "online_movable"), we currently select a zone such that
existing zones are kept contiguous. This online policy made sense in the
past, where contiguous zones where required.
We'd like to implement smarter
For implementing a new memory onlining policy, which determines when to
online memory blocks to ZONE_MOVABLE semi-automatically, we need the number
of present early (boot) pages -- present pages excluding hotplugged pages.
Let's track these pages per zone.
Pass a page instead of the zone to
Hi,
this series is based on v5.14-rc2, with [2] on top. It applies cleanly
on top of linux-next of yesterday.
I. Goal
The goal of this series is improving in-kernel auto-online support. It
tackles the fundamental problems that:
1) We can create zone imbalances when onlining all memory
On Fri, Jul 23, 2021 at 03:06:04AM -0500, Ivan wrote:
> On Fri, Jul 23, 2021 at 2:59 AM Michael S. Tsirkin wrote:
> >
> > On Thu, Jul 22, 2021 at 11:50:11PM -0500, Ivan wrote:
> > > On Thu, Jul 22, 2021 at 11:25 PM Jason Wang wrote:
> > > > 在 2021/7/23 上午10:54, Ivan 写道:
> > > > > On Thu, Jul 22,
On Fri, Jul 23, 2021 at 11:41:31AM +0530, Viresh Kumar wrote:
> Bind the virtio devices with their of_node. This will help users of the
> virtio devices to mention their dependencies on the device in the DT
> itself. Like GPIO pin users can use the phandle of the device node, or
> the node may
On Fri, Jul 23, 2021 at 7:44 AM Jie Deng wrote:
> +
> + ret = virtio_i2c_setup_vqs(vi);
> + if (ret)
> + return ret;
> +
> + vi->adap.owner = THIS_MODULE;
> + snprintf(vi->adap.name, sizeof(vi->adap.name),
> +"i2c_virtio at virtio bus %d",
On Fri, Jul 23, 2021 at 03:31:02AM -0500, Ivan wrote:
> On Fri, Jul 23, 2021 at 2:59 AM Michael S. Tsirkin wrote:
> >
> > On Thu, Jul 22, 2021 at 11:50:11PM -0500, Ivan wrote:
> > > On Thu, Jul 22, 2021 at 11:25 PM Jason Wang wrote:
> > > > 在 2021/7/23 上午10:54, Ivan 写道:
> > > > > On Thu, Jul 22,
On Fri, Jul 23, 2021 at 03:06:04AM -0500, Ivan wrote:
> On Fri, Jul 23, 2021 at 2:59 AM Michael S. Tsirkin wrote:
> >
> > On Thu, Jul 22, 2021 at 11:50:11PM -0500, Ivan wrote:
> > > On Thu, Jul 22, 2021 at 11:25 PM Jason Wang wrote:
> > > > 在 2021/7/23 上午10:54, Ivan 写道:
> > > > > On Thu, Jul 22,
On Thu, Jul 22, 2021 at 11:50:11PM -0500, Ivan wrote:
> On Thu, Jul 22, 2021 at 11:25 PM Jason Wang wrote:
> > 在 2021/7/23 上午10:54, Ivan 写道:
> > > On Thu, Jul 22, 2021 at 9:37 PM Jason Wang wrote:
> > >> Does it work if you turn off lro before enabling the forwarding?
> > > 0 root@NuRaid:~#
Bind the virtio devices with their of_node. This will help users of the
virtio devices to mention their dependencies on the device in the DT
itself. Like GPIO pin users can use the phandle of the device node, or
the node may contain more subnodes to add i2c or spi eeproms and other
users.
18 matches
Mail list logo
