Hi David,
Thanks for tackling this!
On Tue, Oct 22, 2019 at 10:13 AM David Hildenbrand wrote:
>
> This series is based on [2], which should pop up in linux/next soon:
> https://lkml.org/lkml/2019/10/21/1034
>
> This is the result of a recent discussion with Michal ([1], [2]). Right
> now
On Wed, Oct 23, 2019 at 12:26 AM David Hildenbrand wrote:
>
> On 22.10.19 23:54, Dan Williams wrote:
> > Hi David,
> >
> > Thanks for tackling this!
>
> Thanks for having a look :)
>
> [...]
>
>
> >> I am probably a little bit too careful (but
On Wed, Oct 23, 2019 at 10:28 AM David Hildenbrand wrote:
>
> >> I dislike this for three reasons
> >>
> >> a) It does not protect against any races, really, it does not improve
> >> things.
> >> b) We do have the exact same problem with pfn_to_online_page(). As long as
> >> we
> >>don't hol
t enough protection.
>
> Please note that hardware errors (PG_hwpoison) are not memory holes and
> not affected by this change when offlining.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: Pavel Tatashin
> Cc: Dan Williams
> Cc: Anshuman K
_reserved.
>
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Sean Christopherson
> Cc: Vitaly Kuznetsov
> Cc: Wanpeng Li
> Cc: Jim Mattson
> Cc: Joerg Roedel
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin
ges PG_reserved.
>
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Michal Hocko
> Cc: Dan Williams
> Cc: KarimAllah Ahmed
> Signed-off-by: David Hildenbrand
> ---
> virt/kvm/kvm_main.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
&
On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote:
>
> >>> I think I know what's going wrong:
> >>>
> >>> Pages that are pinned via gfn_to_pfn() and friends take a references,
> >>> however are often released via
> >>> kvm_release_pfn_clean()/kvm_release_pfn_dirty()/kvm_release_page_clean().
On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
wrote:
>
> On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand wrote:
> > > > The scarier code (for me) is transparent_hugepage_adjust() and
> > &g
On Tue, Nov 5, 2019 at 3:30 PM Dan Williams wrote:
>
> On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
> wrote:
> >
> > On Tue, Nov 05, 2019 at 03:02:40PM -0800, Dan Williams wrote:
> > > On Tue, Nov 5, 2019 at 12:31 PM David Hildenbrand
> > > wrote:
On Tue, Nov 5, 2019 at 4:03 PM Sean Christopherson
wrote:
>
> On Tue, Nov 05, 2019 at 03:43:29PM -0800, Dan Williams wrote:
> > On Tue, Nov 5, 2019 at 3:30 PM Dan Williams
> > wrote:
> > >
> > > On Tue, Nov 5, 2019 at 3:13 PM Sean Christopherson
> >
On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand wrote:
>
> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
> change that.
>
> KVM has this weird use case that you can map anything from /dev/mem
> into the guest. pfn_valid() is not a reliable check whether the memmap
> was ini
On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
>
> On 07.11.19 19:22, David Hildenbrand wrote:
> >
> >
> >> Am 07.11.2019 um 16:40 schrieb Dan Williams :
> >>
> >> On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand
> >> wrote:
&
On Fri, Nov 8, 2019 at 2:22 AM David Hildenbrand wrote:
>
> On 08.11.19 08:14, David Hildenbrand wrote:
> > On 08.11.19 06:09, Dan Williams wrote:
> >> On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
> >>>
> >>> On 07.11.19 19:22, Davi
[ adding linux-nvdimm ]
Great write up! Some comments below...
On Wed, May 9, 2018 at 10:35 AM, George Dunlap wrote:
> Dan,
>
> I understand that you're the NVDIMM maintainer for Linux. I've been
> working with your colleagues to try to sort out an architecture to allow
> NVRAM to be passed to
On Tue, May 15, 2018 at 5:26 AM, Jan Beulich wrote:
On 15.05.18 at 12:12, wrote:
[..]
>> That is, each fsdax / devdax namespace has a superblock that, in part,
>> defines what parts are used for Linux and what parts are used for data. Or
>> to put it a different way: Linux decides which par
On Tue, May 15, 2018 at 7:19 AM, George Dunlap wrote:
> On 05/11/2018 05:33 PM, Dan Williams wrote:
>> [ adding linux-nvdimm ]
>>
>> Great write up! Some comments below...
>
> Thanks for the quick response!
>
> It seems I still have some fundamental misconception
On Thu, May 17, 2018 at 7:52 AM, George Dunlap wrote:
> On 05/15/2018 07:06 PM, Dan Williams wrote:
>> On Tue, May 15, 2018 at 7:19 AM, George Dunlap
>> wrote:
>>> So, who decides what this SPA range and interleave set is? Can the
>>> operating system change t
On Fri, Sep 21, 2018 at 2:40 AM Arun KS wrote:
>
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improvin
On Fri, Feb 9, 2018 at 6:21 AM, Arnd Bergmann wrote:
> On Fri, Feb 9, 2018 at 3:13 PM, David Laight wrote:
>> From: Arnd Bergmann
>>> Sent: 09 February 2018 12:58
>> ...
>>> However, aside from this driver, I wonder if we should be worried about
>>> Spectre type 1 attacks on similar code, when gc
On Tue, Sep 1, 2020 at 1:33 AM Roger Pau Monne wrote:
>
> This is in preparation for the logic behind MEMORY_DEVICE_DEVDAX also
> being used by non DAX devices.
>
FWIW I would not call this MEMORY_DEVICE_GENERIC. This is really
MEMORY_DEVICE_SIMPLE and the kernel-doc can clarify in contrast to th
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> ---
> fs/cramfs/inode.c | 10 +---
On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote:
>
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized t
: Boris Ostrovsky
Signed-off-by: Dan Williams
---
drivers/xen/unpopulated-alloc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/unpopulated-alloc.c b/drivers/xen/unpopulated-alloc.c
index 8c512ea550bb..75ab5de99868 100644
--- a/drivers/xen
tree at its own pace.
My thanks to Andrew for wrangling the thrash up to v5, and my apologies
to Andrew et al for not highlighting this gap sooner.
[1]:
http://lore.kernel.org/r/160196728453.2166475.12832711415715687418.st...@dwillia2-desk3.amr.corp.intel.com
---
Dan Williams (2):
device
On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand wrote:
>
> On 29.04.20 18:08, David Hildenbrand wrote:
> > Some paravirtualized devices that add memory via add_memory() and
> > friends (esp. virtio-mem) don't want to create entries in
> > /sys/firmware/memmap/ - primarily to hinder kexec from a
On Thu, Apr 30, 2020 at 1:21 AM David Hildenbrand wrote:
> >> Just because we decided to use some DAX memory in the current kernel as
> >> system ram, doesn't mean we should make that decision for the kexec
> >> kernel (e.g., using it as initial memory, placing kexec binaries onto
> >> it, etc.).
On Thu, Apr 30, 2020 at 11:44 AM David Hildenbrand wrote:
>
> >>> If the class of memory is different then please by all means let's mark
> >>> it differently in struct resource so everyone knows it is different.
> >>> But that difference needs to be more than hotplug.
> >>>
> >>> That difference
On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
>
> On 01.05.20 00:24, Andrew Morton wrote:
> > On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand
> > wrote:
> >
> >>>
> >>> Why does the firmware map support hotplug entries?
> >>
> >> I assume:
> >>
> >> The firmware memmap was added p
On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
>
> On 01.05.20 18:56, Dan Williams wrote:
> > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 00:24, Andrew Morton wrote:
> >>> On Thu, 30 Apr 2020 20:4
On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
>
> On 01.05.20 19:45, David Hildenbrand wrote:
> > On 01.05.20 19:39, Dan Williams wrote:
> >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
> >>>
> >>> On 01.05.20 18:56, Dan Willi
On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
>
> On 01.05.20 20:03, Dan Williams wrote:
> > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 19:45, David Hildenbrand wrote:
> >>> On 01.05.20 19:39, Dan Williams
On Fri, May 1, 2020 at 12:18 PM David Hildenbrand wrote:
>
> On 01.05.20 20:43, Dan Williams wrote:
> > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 20:03, Dan Williams wrote:
> >>> On Fri, May 1, 2020 a
On Fri, May 1, 2020 at 2:11 PM David Hildenbrand wrote:
>
> On 01.05.20 22:12, Dan Williams wrote:
[..]
> >>> Consider the case of EFI Special Purpose (SP) Memory that is
> >>> marked EFI Conventional Memory with the SP attribute. In that case the
> >
On Sat, May 2, 2020 at 2:27 AM David Hildenbrand wrote:
>
> >> Now, let's clarify what I want regarding virtio-mem:
> >>
> >> 1. kexec should not add virtio-mem memory to the initial firmware
> >>memmap. The driver has to be in charge as discussed.
> >> 2. kexec should not place kexec images o
--
> block/blk-lib.c | 2 +-
> drivers/block/brd.c | 3 ---
> drivers/block/null_blk_main.c| 4
> drivers/block/zram/zram_drv.c| 8
> drivers/block/zram/zram_drv.h| 2 --
> drivers/dax/super.c | 2 +-
For
/drivers/nvdimm/claim.c
> +++ b/drivers/nvdimm/claim.c
> @@ -200,11 +200,10 @@ ssize_t nd_namespace_store(struct device *dev,
> }
> break;
> default:
> len = -EBUSY;
> goto out_attach;
> - break;
> }
Acked-by: Dan Williams
> implemented buses return an ignored error code and so don't anticipate
> wrong expectations for driver authors.
>
> drivers/cxl/core.c| 3 +--
> drivers/dax/bus.c | 4 +---
> drivers/nvdimm/bus.c | 3 +--
For CXL, DAX, and NVDIMM
Acked-by: Dan Williams
37 matches
Mail list logo
