lkml.org 
[lkml]   [2007]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: slub-i386-support.patch
    William Lee Irwin III wrote:
    >> Xen is not mandatory as it now stands.

    On Thu, May 10, 2007 at 02:28:05PM -0700, Jeremy Fitzhardinge wrote:
    > ? I'm hoping to merge the Xen code in the next couple of days, so I'd
    > appreciate it if we don't break the foundations just before building the
    > building.

    CONFIG_X86_PAE without CONFIG_PARAVIRT is the case in question here.
    What's done in that case can't break Xen because it doesn't run under
    Xen.


    William Lee Irwin III wrote:
    >> Also, I intend to fix up Xen
    >> at some point so it doesn't need this.

    On Thu, May 10, 2007 at 02:28:05PM -0700, Jeremy Fitzhardinge wrote:
    > As I mentioned in the previous mail, its only really necessary for a
    > 32-bit guest under a 32-bit hypervisor. While that's going to be a
    > supported configuration for a long time, we expect that people will
    > increasingly use 64-bit hypervisors on new machines, so this will become
    > less of an issue.
    > We're also looking at shadowing the 4 top-level PAE entries rather than
    > using them directly, since the shadows only need to be updated when
    > reloading cr3. This would allow us to use compact pgds, so long as
    > there's some other way to maintain the pgd list (ideally, something that
    > can be shared with non-PAE).

    ISTR you describing this method earlier. This is what I had in mind
    for fixing up Xen not to need full PAGE_SIZE-sized pgd's.


    On Thu, May 10, 2007 at 02:28:05PM -0700, Jeremy Fitzhardinge wrote:
    > Or did I miss something? Is pgd_list being maintained some other way
    > with slub/quicklists?

    No, it's identical. clameter's code makes PAGE_SIZE-sized pgd's
    unconditional for CONFIG_X86_PAE, which is what bothered me.


    William Lee Irwin III wrote:
    >> The alternative was 64-bit generation numbers incremented at the time
    >> of change_page_attr(). If generation numbers were used, it would be
    >> possible to dispose of the list altogether. Given the awkwardness of
    >> the list maintenance for Xen, it may be worth using them now. PAE
    >> pgd's could merely double in size to maintain those for the unshared
    >> kernel pmd case, and remain 32B otherwise. Full PAGE_SIZE -sized pgd's
    >> for 2-level pagetables could distribute the generation number across
    >> page->index and page->private, or any other fields available.

    On Thu, May 10, 2007 at 02:28:05PM -0700, Jeremy Fitzhardinge wrote:
    > If you use page->index for that, how does pgd_list get linked together
    > for vmalloc syncing?

    It doesn't need to be linked together for vmalloc_sync(). Just increment
    the generation number and walk the mmlist the same as for pageattr.c


    -- wli
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-11 01:37    [W:0.025 / U:1.468 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site