Williams
Tested-by: Alison Schofield
Reviewed-by: Jonathan Cameron
Acked-by: David Hildenbrand
Signed-off-by: Gregory Price
---
drivers/dax/kmem.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index e97d47f42ee2
On Wed, Apr 09, 2025 at 03:21:53PM -0700, Alison Schofield wrote:
> Existing unit test 'daxctl-devices.sh' hits this case:
> [ 52.547521] kmem dax3.0: DAX region truncated by 62.0 MiB due to alignment
>
> Tested-by: Alison Schofield
>
Thanks for testing, good to know there's an existing test f
vendors to
pay attention to - so this truncation should not be silent.
This issue is particularly relevant for CXL Dynamic Capacity devices,
whose capacity may arrive in spec-aligned but block-misaligned chunks.
Suggested-by: David Hildenbrand
Suggested-by: Dan Williams
Signed-off-by: Gregory
On Tue, Apr 01, 2025 at 10:47:09AM -0700, Dan Williams wrote:
> David Hildenbrand wrote:
> > diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> > index e97d47f42ee2e..23a68ff809cdf 100644
> > --- a/drivers/dax/kmem.c
> > +++ b/drivers/dax/kmem.c
> > @@ -67,8 +67,8 @@ static void kmem_put_memory
On Tue, Apr 01, 2025 at 05:19:28PM +0200, David Hildenbrand wrote:
>
> Yes, it's valuable I think. But should it be a warning or rather an info?
>
dev_warn, but yeah I think so? A user expects to get their memory in
full, that means we're slightly misbehaving. I'm fine with either.
~Gregory
On Tue, Apr 01, 2025 at 04:50:40PM +0200, David Hildenbrand wrote:
>
> Oh, you mean with the whole memmap_on_memory thing. Even with that, using
> 2GB memory blocks would only fit a single 1GB memory block ... and it
> requires ZONE_NORMAL.
>
> For ordinary boot memory, the 1GB behavior should be
On Tue, Apr 01, 2025 at 11:47:32AM +0200, David Hildenbrand wrote:
>
> Can't that be done a bit simpler?
Yes, this is better, lets do this. Thank you!
>
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index e97d47f42ee2e..23a68ff809cdf 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers
On Tue, Apr 01, 2025 at 11:33:59AM +0200, David Hildenbrand wrote:
> On 31.03.25 20:27, Gregory Price wrote:
> > We discussed [1] how this auto-sizing can cause 1GB huge page
> > allocation failures (assuming you online as ZONE_NORMAL). That means
> > ACPI-informed si
On Fri, Mar 21, 2025 at 02:07:31PM -0400, Gregory Price wrote:
> Device capacity intended for use as system ram should be aligned to the
> architecture-defined memory block size or that capacity will be silently
> truncated and capacity stranded.
>
> As hotplug dax memory becomes
[...] kmem dax1.0: dax region truncated 1610612736 bytes - alignment
Signed-off-by: Gregory Price
---
drivers/dax/kmem.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index e97d47f42ee2..15b6807b703d 100644
--- a
being the current
> node id as well. More refactoring is required for to simplify that.
>
> Signed-off-by: Ackerley Tng
Reviewed-by: Gregory Price
> +/**
> + * policy_node_nodemask(@mpol, @gfp_flags, @ilx, @nodemask)
> + * @mpol: the memory policy to interpret. Reference m
On Mon, Apr 08, 2024 at 10:41:04PM +0900, Honggyu Kim wrote:
> Hi Gregory,
>
> On Fri, 5 Apr 2024 12:56:14 -0400 Gregory Price
> wrote:
> > Do you have test results which enable only DAMOS_MIGRATE_COLD actions
> > but not DAMOS_MIGRATE_HOT actions? (and vice versa)
>
On Fri, Apr 05, 2024 at 03:08:49PM +0900, Honggyu Kim wrote:
> There was an RFC IDEA "DAMOS-based Tiered-Memory Management" previously
> posted at [1].
>
> 1. YCSB zipfian distribution read only workload
> memory pressure with cold memory on node0 with 512GB of local DRAM.
> =+==
13 matches
Mail list logo
