Messages in this thread | | | Date | Mon, 18 May 2015 23:04:18 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH 10/19] x86, mpx: trace ranged MPX operations |
| |
On Fri, 8 May 2015, Dave Hansen wrote: > When MPX can not free an entire bounds table, it will instead > try to zap unused parts of a bounds table to free the backing > memory. This decreases RSS (resident set size) without > decreasing the virtual space allocated for bounds tables. > > trace attempts to find bounds tables:
My first reading was: "The trace attempts to find bounds tables"
"Trace the attempts to find bounds tables" is what you actually mean.
> This event traces any time we go looking to unmap a bounds table
You have two events ....
> for a given virtual address range. This is useful to ensure > that the kernel actually "tried" to free a bounds table versus > times it succeeded. > > It might try and fail if it realized that a table was shared > with an adjacent VMA which is not being unmapped.
So rewording that would probably create a useful changelog.
Thanks,
tglx
| |