Ingo Molnar wrote:
> I think this is too complex.
>
> How about something simple like the patch below (on top of the third patch)?
> It makes the vmalloc info transactional - /proc/meminfo will always print a
> consistent set of numbers. (Not that we really care about races there, but it
>
* George Spelvin wrote:
> Linus wrote:
> > I don't think any of this can be called "correct", in that the
> > unlocked accesses to the cached state are clearly racy, but I think
> > it's very much "acceptable".
>
> I'd think you could easily fix that with a seqlock-like system.
>
> What makes
* George Spelvin li...@horizon.com wrote:
Linus wrote:
I don't think any of this can be called correct, in that the
unlocked accesses to the cached state are clearly racy, but I think
it's very much acceptable.
I'd think you could easily fix that with a seqlock-like system.
What
Ingo Molnar mi...@kernel.org wrote:
I think this is too complex.
How about something simple like the patch below (on top of the third patch)?
It makes the vmalloc info transactional - /proc/meminfo will always print a
consistent set of numbers. (Not that we really care about races there,
Linus wrote:
> I don't think any of this can be called "correct", in that the
> unlocked accesses to the cached state are clearly racy, but I think
> it's very much "acceptable".
I'd think you could easily fix that with a seqlock-like system.
What makes it so simple is that you can always fall
On Sat, Aug 22, 2015 at 3:44 AM, Ingo Molnar wrote:
>
> Would something like this be acceptable (and is it correct)?
I don't think any of this can be called "correct", in that the
unlocked accesses to the cached state are clearly racy, but I think
it's very much "acceptable".
This series is a variant of Linus's jiffies based caching approach in the:
"get_vmalloc_info() and /proc/meminfo insanely expensive"
thread on lkml.
The idea is to track modifications to the vmalloc list by wrapping the
lock/unlock primitives, and to put a flag next to the spinlock. If the
This series is a variant of Linus's jiffies based caching approach in the:
get_vmalloc_info() and /proc/meminfo insanely expensive
thread on lkml.
The idea is to track modifications to the vmalloc list by wrapping the
lock/unlock primitives, and to put a flag next to the spinlock. If the
On Sat, Aug 22, 2015 at 3:44 AM, Ingo Molnar mi...@kernel.org wrote:
Would something like this be acceptable (and is it correct)?
I don't think any of this can be called correct, in that the
unlocked accesses to the cached state are clearly racy, but I think
it's very much acceptable.
Linus wrote:
I don't think any of this can be called correct, in that the
unlocked accesses to the cached state are clearly racy, but I think
it's very much acceptable.
I'd think you could easily fix that with a seqlock-like system.
What makes it so simple is that you can always fall back to
10 matches
Mail list logo
