On Tue 30-06-20 17:27:13, Andrew Morton wrote:
> On Mon, 29 Jun 2020 09:57:42 -0700 Tim Chen
> wrote:
> > I am okay with Matthew's suggestion of keeping the stack pagevec size
> > unchanged.
> > Andrew, do you have a preference?
> >
> > I was assuming that for people who really care about savin
On Mon, 29 Jun 2020 09:57:42 -0700 Tim Chen wrote:
>
>
> I am okay with Matthew's suggestion of keeping the stack pagevec size
> unchanged.
> Andrew, do you have a preference?
>
> I was assuming that for people who really care about saving the kernel memory
> usage, they would make CONFIG_NR_
On 6/26/20 8:47 PM, Andrew Morton wrote:
> On Sat, 27 Jun 2020 04:13:04 +0100 Matthew Wilcox wrote:
>
>> On Fri, Jun 26, 2020 at 02:23:03PM -0700, Tim Chen wrote:
>>> Enlarge the pagevec size to 31 to reduce LRU lock contention for
>>> large systems.
>>>
>>> The LRU lock contention is reduced
On Sat, 27 Jun 2020 04:13:04 +0100 Matthew Wilcox wrote:
> On Fri, Jun 26, 2020 at 02:23:03PM -0700, Tim Chen wrote:
> > Enlarge the pagevec size to 31 to reduce LRU lock contention for
> > large systems.
> >
> > The LRU lock contention is reduced from 8.9% of total CPU cycles
> > to 2.2% of CPU
On Fri, Jun 26, 2020 at 02:23:03PM -0700, Tim Chen wrote:
> Enlarge the pagevec size to 31 to reduce LRU lock contention for
> large systems.
>
> The LRU lock contention is reduced from 8.9% of total CPU cycles
> to 2.2% of CPU cyles. And the pmbench throughput increases
> from 88.8 Mpages/sec to
Pages to be added to a LRU are first cached in pagevec before being
added to LRU in a batch via pagevec_lru_move_fn. By adding the pages
in a batch with pagevec, the contention on LRU lock is mitigated.
Currently the pagevec size is defined to be 15.
We found during testing on a large SMT system
6 matches
Mail list logo
