Re: [PATCH v2 1/1] rcu/kvfree: Update KFREE_DRAIN_JIFFIES interval

From: Uladzislau Rezki
Date: Tue Jun 28 2022 - 08:02:42 EST


On Tue, Jun 28, 2022 at 01:45:31PM +0200, Uladzislau Rezki wrote:
> > On Mon, Jun 27, 2022 at 09:53:53PM +0200, Uladzislau Rezki (Sony) wrote:
> > > Currently the monitor work is scheduled with a fixed interval that
> > > is HZ/20 or each 50 milliseconds. The drawback of such approach is
> > > a low utilization of page slot in some scenarios. The page can store
> > > up to 512 records. For example on Android system it can look like:
> >
> > I was looking at queuing this one, but we need a bit more data. In
> > the meantime, here is my wordsmithing of the above paragraph:
> >
> > Currently the monitor work is scheduled with a fixed interval of HZ/20,
> > which is roughly 50 milliseconds. The drawback of this approach is
> > low utilization of the 512 page slots in scenarios with infrequence
> > kvfree_rcu() calls. For example on an Android system:
> >
> Good i will update with your changes :)
>
> > > <snip>
> > > kworker/3:0-13872 [003] .... 11286.007048: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000026522604 nr_records=1
> > > kworker/3:0-13872 [003] .... 11286.015638: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000095ed6fca nr_records=2
> > > kworker/1:2-20434 [001] .... 11286.051230: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000044872ffd nr_records=1
> > > kworker/1:2-20434 [001] .... 11286.059322: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000026522604 nr_records=2
> > > kworker/0:1-20052 [000] .... 11286.095295: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000044872ffd nr_records=2
> > > kworker/0:1-20052 [000] .... 11286.103418: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x00000000cbcf05db nr_records=1
> > > kworker/2:3-14372 [002] .... 11286.135155: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000095ed6fca nr_records=2
> > > kworker/2:3-14372 [002] .... 11286.135198: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000044872ffd nr_records=1
> > > kworker/1:2-20434 [001] .... 11286.155377: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x00000000cbcf05db nr_records=5
> > > kworker/2:3-14372 [002] .... 11286.167181: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000026522604 nr_records=5
> > > kworker/1:2-20434 [001] .... 11286.179202: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x000000008ef95e14 nr_records=1
> > > kworker/2:3-14372 [002] .... 11286.187398: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x00000000c597d297 nr_records=6
> > > kworker/3:0-13872 [003] .... 11286.187445: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000050bf92e2 nr_records=3
> > > kworker/1:2-20434 [001] .... 11286.198975: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x00000000cbcf05db nr_records=4
> > > kworker/1:2-20434 [001] .... 11286.207203: rcu_invoke_kfree_bulk_callback: rcu_preempt bulk=0x0000000095ed6fca nr_records=4
> > > <snip>
> > >
> > > where a page only carries few records to reclaim a memory. In order
> > > to improve batching and make utilization more efficient the patch sets
> > > a drain interval to 1 second as default one. When a flood is detected
> > > an interval is adjusted in a way that a reclaim work is re-scheduled
> > > on a next timer jiffy.
> >
> > And of the above paragraph:
> >
> > Out of 512 slots, in all cases, fewer than 10 were actually used.
> > In order to improve batching and make utilization more efficient this
> > commit sets a drain interval to a fixed 1-second interval. Floods are
> > detected when a page fills quickly, and in that case, the reclaim work
> > is re-scheduled for the next scheduling-clock tick (jiffy).
> >
> Same here, will apply this.
>
> > ---
> >
> > But what we need now is a trace like the one above showing higher utilization
> > of the pages. Could you please supply this?
> >
> Yep, i will add traces to show that utilization becomes better what is
> actually expectable.
>
> --
> Uladzislau Rezki
Paul, see below the v3: