[PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M - Kernel

This is a discussion on [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M - Kernel ; * Yinghai Lu wrote: > > boundary handling may have problem... > > can you try > > diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c > index ef64128..70beb13 100644 > --- a/arch/x86/kernel/cpu/mtrr/main.c > +++ b/arch/x86/kernel/cpu/mtrr/main.c > @@ -1044,7 +1044,7 @@ second_try: > hole_sizek ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

  1. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M


    * Yinghai Lu wrote:

    > > boundary handling may have problem...

    >
    > can you try
    >
    > diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
    > index ef64128..70beb13 100644
    > --- a/arch/x86/kernel/cpu/mtrr/main.c
    > +++ b/arch/x86/kernel/cpu/mtrr/main.c
    > @@ -1044,7 +1044,7 @@ second_try:
    > hole_sizek = range0_sizek - state->range_sizek - second_sizek;
    >
    > /* hole size should be less than half of range0 size */
    > - if (hole_sizek > (range0_sizek >> 1) &&
    > + if (hole_sizek >= (range0_sizek >> 1) &&
    > range0_sizek >= chunk_sizek) {


    applied to tip/x86/mtrr, thanks Yinghai!

    Ingo
    --
    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/

  2. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M


    * J.A. Magallˇn wrote:

    > Also, on a 64 bit box with 4Gb, it gives this:
    >
    > cicely:~# cat /proc/mtrr
    > reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
    > reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
    >
    > Patch below cleans up formatting, with space for big bases and sizes (64 Gb).


    applied to tip/x86/mtrr, thanks!

    > +++ arch/x86/kernel/cpu/mtrr/if.c 2008-10-03 00:22:34.000000000 +0200
    > @@ -16,7 +16,7 @@
    > static const char *const mtrr_strings[MTRR_NUM_TYPES] =
    > {
    > "uncachable", /* 0 */
    > - "write-combining", /* 1 */
    > + "write-combine", /* 1 */


    hm, maybe this bit could confuse versions of Xorg that modifies
    /proc/mtrr - i.e. this could be part of the ABI towards user-space.
    We'll see.

    Ingo
    --
    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/

  3. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M


    * H. Peter Anvin wrote:

    > Ingo Molnar wrote:
    >> * J.A. Magallˇn wrote:
    >>
    >>> Also, on a 64 bit box with 4Gb, it gives this:
    >>>
    >>> cicely:~# cat /proc/mtrr
    >>> reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    >>> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    >>> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    >>> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
    >>> reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
    >>>
    >>> Patch below cleans up formatting, with space for big bases and sizes (64 Gb).

    >>
    >> applied to tip/x86/mtrr, thanks!
    >>
    >>> +++ arch/x86/kernel/cpu/mtrr/if.c 2008-10-03 00:22:34.000000000 +0200
    >>> @@ -16,7 +16,7 @@
    >>> static const char *const mtrr_strings[MTRR_NUM_TYPES] =
    >>> {
    >>> "uncachable", /* 0 */
    >>> - "write-combining", /* 1 */
    >>> + "write-combine", /* 1 */

    >>
    >> hm, maybe this bit could confuse versions of Xorg that modifies
    >> /proc/mtrr - i.e. this could be part of the ABI towards user-space.
    >> We'll see.
    >>

    >
    > This *IS* part of the ABI toward userspace, although I think Xorg uses
    > the ioctl() interface.


    yeah, but aspects of the ABI that applications do not rely on can
    generally be changed. OTOH, i've undone this aspect of the patch -
    /proc/mtrr is a legacy interface and changes to it are unnecessary. I
    kept the boot printout cleanups.

    Ingo
    --
    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/

  4. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    On Fri, 3 Oct 2008 09:37:27 +0200, Ingo Molnar wrote:

    >
    > * J.A. Magall├│n wrote:
    >
    > > Also, on a 64 bit box with 4Gb, it gives this:
    > >
    > > cicely:~# cat /proc/mtrr
    > > reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
    > > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
    > > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
    > > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
    > > reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
    > >
    > > Patch below cleans up formatting, with space for big bases and sizes (64 Gb).

    >
    > applied to tip/x86/mtrr, thanks!
    >
    > > +++ arch/x86/kernel/cpu/mtrr/if.c 2008-10-03 00:22:34.000000000 +0200
    > > @@ -16,7 +16,7 @@
    > > static const char *const mtrr_strings[MTRR_NUM_TYPES] =
    > > {
    > > "uncachable", /* 0 */
    > > - "write-combining", /* 1 */
    > > + "write-combine", /* 1 */

    >
    > hm, maybe this bit could confuse versions of Xorg that modifies
    > /proc/mtrr - i.e. this could be part of the ABI towards user-space.
    > We'll see.
    >
    > Ingo


    Oops, it's not only used for messages, also for writes in /proc !!!

    Forget this part.

    --
    J.A. Magallon \ Software is like sex:
    \ It's better when it's free
    Mandriva Linux release 2009.0 (Cooker) for i586
    Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP
    --
    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/

  5. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    Ingo Molnar wrote:
    >
    >> +++ arch/x86/kernel/cpu/mtrr/if.c 2008-10-03 00:22:34.000000000 +0200
    >> @@ -16,7 +16,7 @@
    >> static const char *const mtrr_strings[MTRR_NUM_TYPES] =
    >> {
    >> "uncachable", /* 0 */
    >> - "write-combining", /* 1 */
    >> + "write-combine", /* 1 */

    >
    > hm, maybe this bit could confuse versions of Xorg that modifies
    > /proc/mtrr - i.e. this could be part of the ABI towards user-space.
    > We'll see.
    >


    By the way, this is just plain wrong; the cachability name is "Write
    Combining (WC)" not "write-combine".

    -hpa
    --
    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/

  6. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M


    * H. Peter Anvin wrote:

    > Ingo Molnar wrote:
    >>
    >>> +++ arch/x86/kernel/cpu/mtrr/if.c 2008-10-03 00:22:34.000000000 +0200
    >>> @@ -16,7 +16,7 @@
    >>> static const char *const mtrr_strings[MTRR_NUM_TYPES] =
    >>> {
    >>> "uncachable", /* 0 */
    >>> - "write-combining", /* 1 */
    >>> + "write-combine", /* 1 */

    >>
    >> hm, maybe this bit could confuse versions of Xorg that modifies
    >> /proc/mtrr - i.e. this could be part of the ABI towards user-space.
    >> We'll see.
    >>

    >
    > By the way, this is just plain wrong; the cachability name is "Write
    > Combining (WC)" not "write-combine".


    and "uncachable" should be "uncacheable" i guess.

    anyway, agreed, lets not touch this.

    Ingo
    --
    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/

  7. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    Ingo Molnar wrote:
    >>>
    >>>> +++ arch/x86/kernel/cpu/mtrr/if.c 2008-10-03 00:22:34.000000000 +0200
    >>>> @@ -16,7 +16,7 @@
    >>>> static const char *const mtrr_strings[MTRR_NUM_TYPES] =
    >>>> {
    >>>> "uncachable", /* 0 */
    >>>> - "write-combining", /* 1 */
    >>>> + "write-combine", /* 1 */
    >>> hm, maybe this bit could confuse versions of Xorg that modifies
    >>> /proc/mtrr - i.e. this could be part of the ABI towards user-space.
    >>> We'll see.
    >>>

    >> This *IS* part of the ABI toward userspace, although I think Xorg uses
    >> the ioctl() interface.

    >
    > yeah, but aspects of the ABI that applications do not rely on can
    > generally be changed. OTOH, i've undone this aspect of the patch -
    > /proc/mtrr is a legacy interface and changes to it are unnecessary. I
    > kept the boot printout cleanups.
    >


    Great. It's worth noting that these strings aren't just used for
    readout, but also for setting.

    -hpa
    --
    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/

  8. Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

    | From: H. Peter Anvin

    | Ingo Molnar wrote:
    | > * J.A. Magall├│n wrote:

    | > > +++ arch/x86/kernel/cpu/mtrr/if.c 2008-10-03 00:22:34.000000000 +0200
    | > > @@ -16,7 +16,7 @@
    | > > static const char *const mtrr_strings[MTRR_NUM_TYPES] =
    | > > {
    | > > "uncachable", /* 0 */
    | > > - "write-combining", /* 1 */
    | > > + "write-combine", /* 1 */
    | >
    | > hm, maybe this bit could confuse versions of Xorg that modifies /proc/mtrr -
    | > i.e. this could be part of the ABI towards user-space. We'll see.
    | >
    |
    | This *IS* part of the ABI toward userspace, although I think Xorg uses the
    | ioctl() interface.

    My mtrr-uncover program uses this interface.

    One reason is that the ioctl interface is broken. See
    http://lkml.org/lkml/2008/8/5/62

    I too understand that Xorg drivers uses the ioctl interface. Since
    they only use it on video device buffers, and those buffers always
    seem to start and end below 4GiB, the ioctl bugs probably don't affect
    Xorg.

    The ioctl bugs do mean that Xorg drivers cannot even see the MTRR
    nesting problems let alone address them.

    The ib_path driver apparently uses MTRRs in a way analogous to Xorg
    drivers. There is a script that is part of Fedora that uses the
    /proc/mtrr interface to attempt to fix nested MTRRs:
    http://cvs.fedora.redhat.com/viewvc/...fixup-mtrr.awk

    There may well be other users of this API. Or is it an ABI. I'm not sure.

    It would be useful to know what code exists that uses the
    MTRR-changing interfaces. I only know about the ones I've mentioned
    above. Does anyone know of others?

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2