linux-kernel - Re: Please revert [PATCH] user of the jiffies rounding patch: Slab

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] [day] [month] [year] [list]

Date:	Mon, 30 Apr 2007 12:28:07 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
cc:	akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: Please revert [PATCH] user of the jiffies rounding patch: Slab

On Mon, 30 Apr 2007, Arjan van de Ven wrote:

> Christoph Lameter wrote:
> > Umm you did not read the last bit of the description? It talks about firing
> > all timers on all cpus at once.
> >  
> 
> it talks about AVOIDING firing all timers on all cpus at once.

Hmmmm... Looked fine right now. Must have gotten the deep end before.

Ok. Could you review the new 1 HZ timer that I added to vmstat.c in mm and 
make sure that it does the right thing? I'd like to have that one run at 
an jiffy offset of 1 instead of 3 to give you more quiet time. 

That one is only used for SMP. With SLUB there will be no periodic timers 
at all for UP. SMP only has the vmstats update which should be quite 
lightweight compared to the slab reaper and it does not need this long 
period between them to be safe.

I'd like to have some ideas from you for NUMA. On NUMA I would like to 
have all vm statistics refresh actions on each node be synchronized (which 
would also significantly fix the situation on large NUMA for you).

I.e. on HZ the first cpus of each node run vmstats update, on HZ + 1 the 
second cpu run its etc. How could we make that work?

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