Hi Nuno,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on asm-generic/master]
[cannot apply to tip/master linux/master linus/master tip/x86/core v5.14-rc4
next-20210806]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Hi Nuno,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on asm-generic/master]
[cannot apply to tip/master linux/master linus/master tip/x86/core v5.14-rc4
next-20210806]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Fri, Aug 6, 2021 at 5:01 AM Xianting Tian
wrote:
> @@ -163,6 +155,13 @@ static void hvc_console_print(struct console *co, const
> char *b,
> if (vtermnos[index] == -1)
> return;
>
> + list_for_each_entry(hp, _structs, next)
> + if (hp->vtermno ==
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..8945f248ce69 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-rc3, with [2] on top.
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 blindly to
ZONE_MOVABLE, in the worst case crashing the
> From: Michael S. Tsirkin
> Sent: Friday, August 6, 2021 2:12 PM
> > enum vdpa_attr {
> > @@ -33,6 +34,16 @@ enum vdpa_attr {
> > VDPA_ATTR_DEV_MAX_VQS, /* u32 */
> > VDPA_ATTR_DEV_MAX_VQ_SIZE, /* u16 */
> > + VDPA_ATTR_DEV_NET_CFG_MACADDR,
On Fri, Aug 06, 2021 at 11:40:38AM +0300, Arseny Krasnov wrote:
On 06.08.2021 10:28, Stefano Garzarella wrote:
Caution: This is an external email. Be cautious while opening links or
attachments.
On Mon, Jul 26, 2021 at 07:33:38PM +0300, Arseny Krasnov wrote:
It works in the same way as
On Fri, Aug 06, 2021 at 10:50:27AM +0800, Jason Wang wrote:
>
> 在 2021/8/5 下午5:57, Michael S. Tsirkin 写道:
> > On Wed, Jun 16, 2021 at 10:11:49PM +0300, Parav Pandit wrote:
> > > Currently user cannot set the mac address and mtu of the vdpa device.
> > > This patchset enables users to set the mac
On 05-08-21, 15:10, Arnd Bergmann wrote:
> I hope this can still be simplified by working out better which state
> transitions are needed exactly. In particular, I would expect that we
> can get away with not sending a VIRTIO_GPIO_MSG_IRQ_TYPE
> for 'mask' state changes at all, but use that only
On Mon, Jul 26, 2021 at 07:33:38PM +0300, Arseny Krasnov wrote:
It works in the same way as 'end-of-message' bit: if packet has
'EOM' bit, also check for 'EOR' bit.
Signed-off-by: Arseny Krasnov
---
drivers/vhost/vsock.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff
On Mon, Jul 26, 2021 at 07:33:25PM +0300, Arseny Krasnov wrote:
As 'record' is not same as 'message', rename current variables,
comments and defines from 'record' concept to 'message'.
Signed-off-by: Arseny Krasnov
---
drivers/vhost/vsock.c | 18 +-
On Mon, Jul 26, 2021 at 07:33:04PM +0300, Arseny Krasnov wrote:
This bit is used to mark end of messages('EOM' - end of message), while
'VIRIO_VSOCK_SEQ_EOR' is used to pass MSG_EOR.
Signed-off-by: Arseny Krasnov
---
include/uapi/linux/virtio_vsock.h | 1 +
1 file changed, 1 insertion(+)
diff
On Thu, Aug 05, 2021 at 12:21:57PM +0300, Arseny Krasnov wrote:
On 05.08.2021 12:06, Stefano Garzarella wrote:
Caution: This is an external email. Be cautious while opening links or
attachments.
On Thu, Aug 05, 2021 at 11:33:12AM +0300, Arseny Krasnov wrote:
On 04.08.2021 15:57, Stefano
21 matches
Mail list logo
