linux-kernel - Re: [PATCH] x86: fix /proc/meminfo DirectMap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Aug 2008 15:45:45 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: fix /proc/meminfo DirectMap


* Hugh Dickins <hugh@...itas.com> wrote:

> On Fri, 15 Aug 2008, Andi Kleen wrote:
> > On Fri, Aug 15, 2008 at 01:58:32PM +0100, Hugh Dickins wrote:
> > > Do we actually want these DirectMap lines in the x86 /proc/meminfo?
> > > I can see they're interesting to CPA developers and TLB optimizers,
> > > but they don't fit its usual "where has all my memory gone?" usage.
> > 
> > It was intended for the "why is my computer going slower" usage.
> 
> Yes, that's what I meant by the TLB optimizers.  But it's going to be 
> a fractional effect, isn't it, when you're trying to get the last 1% 
> out of the machine?  And in such a case, you might wonder more what 
> all the 4k ones are actually being used for (no problem at all if 
> they've ended up behind vmalloced module text).

i cannot see any performance difference myself between 2MB and 1GB TLBs.

There are measurements that Andi Kleen did originally in this commit:

 commit 8346ea17aa20e9864b0f7dc03d55f3cd5620b8c1
 Author: Andi Kleen <andi@...stfloor.org>
 Date:   Wed Mar 12 03:53:32 2008 +0100

    x86: split large page mapping for AMD TSEG

    [lower is better]
                  no split stddev         split  stddev    delta
    Elapsed Time   87.146 (0.727516)     84.296 (1.09098)  -3.2%
    User Time     274.537 (4.05226)     273.692 (3.34344)  -0.3%
    System Time    34.907 (0.42492)      34.508 (0.26832)  -1.1%
    Percent CPU   322.5   (38.3007)     326.5   (44.5128)  +1.2%

    => About 3.2% improvement in elapsed time for kernbench.
 [...]

meanwhile i have Barcelona class hardware myself and i cannot reproduce 
these claimed improvements in kernbench performance. gbpages versus 
no-gbpages results are dead on the same, within statistical noise.

( i'm sure it could make some difference in synthetic user-space 
  workloads - but gbpages are not exposed to user-space anyway. )

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