lkml.org 
[lkml]   [2018]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v1 00/10] mm: online/offline 4MB chunks controlled by device driver
    From
    Date
    On 28.05.2018 10:28, Dave Young wrote:
    > On 05/24/18 at 11:14am, David Hildenbrand wrote:
    >> On 24.05.2018 10:56, Dave Young wrote:
    >>> Hi,
    >>>
    >>> [snip]
    >>>>>
    >>>>>> For kdump and onlining/offlining code, we
    >>>>>> have to mark pages as offline before a new segment is visible to the system
    >>>>>> (e.g. as these pages might not be backed by real memory in the hypervisor).
    >>>>>
    >>>>> Please expand on the kdump part. That is really confusing because
    >>>>> hotplug should simply not depend on kdump at all. Moreover why don't you
    >>>>> simply mark those pages reserved and pull them out from the page
    >>>>> allocator?
    >>>>
    >>>> 1. "hotplug should simply not depend on kdump at all"
    >>>>
    >>>> In theory yes. In the current state we already have to trigger kdump to
    >>>> reload whenever we add/remove a memory block.
    >>>>
    >>>>
    >>>> 2. kdump part
    >>>>
    >>>> Whenever we offline a page and tell the hypervisor about it ("unplug"),
    >>>> we should not assume that we can read that page again. Now, if dumping
    >>>> tools assume they can read all memory that is offline, we are in trouble.
    >>>>
    >>>> It is the same thing as we already have with Pg_hwpoison. Just a
    >>>> different meaning - "don't touch this page, it is offline" compared to
    >>>> "don't touch this page, hw is broken".
    >>>
    >>> Does that means in case an offline no kdump reload as mentioned in 1)?
    >>>
    >>> If we have the offline event and reload kdump, I assume the memory state
    >>> is refreshed so kdump will not read the memory offlined, am I missing
    >>> something?
    >>
    >> If a whole section is offline: yes. (ACPI hotplug)

    After my investigation and reply to the other subthread, I think this is
    not the case.

    If a section/memory block is offline, it will currently still be dumped
    as far as I can see. The ONLINE flag for sections is not (yet)
    interpreted in makedumpfile.

    >>
    >> If pages are online but broken ("logically offline" - hwpoison): no
    >>
    >> If single pages are logically offline: no. (Balloon inflation - let's
    >> call it unplug as that's what some people refer to)
    >>
    >> If only subsections (4MB chunks) are offline: no.
    >>
    >> Exporting memory ranges in a smaller granularity to kdump than section
    >> size would a) be heavily complicated b) introduce a lot of overhead for
    >> this tracking data c) make us retrigger kdump way too often.
    >>
    >> So simply marking pages offline in the struct pages and telling kdump
    >> about it is the straight forward thing to do. And it is fairly easy to
    >> add and implement as we have the exact same thing in place for hwpoison.
    >
    > Ok, it is clear enough. If case fine grained page offline is is like
    > a hwpoison page so a userspace patch for makedumpfile is needes to
    > exclude them when copying vmcore.

    Exactly, to not touch pages that have no backing in the hypervisor. Even
    if the pages would be readable on the hypervisor side, it makes no sense
    to read/process them, as the y are logically offline and the content is
    of no importance anymore - performance improvement, possible dump size
    reduction.

    --

    Thanks,

    David / dhildenb

    \
     
     \ /
      Last update: 2018-05-28 12:03    [W:3.130 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site