Rename kfree_call_rcu() to the kvfree_call_rcu().
The reason is, it is capable of freeing vmalloc()
memory now.
Do the same with __kfree_rcu() macro, it becomes
__kvfree_rcu(), the reason is the same as pointed
above.
Signed-off-by: Uladzislau Rezki (Sony) <[email protected]>
---
include/linux/rcupdate.h | 8 ++++----
include/linux/rcutiny.h | 2 +-
include/linux/rcutree.h | 2 +-
kernel/rcu/tree.c | 8 ++++----
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index e4961631a44f..6c660fa1f551 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -805,10 +805,10 @@ static inline notrace void rcu_read_unlock_sched_notrace(void)
/*
* Helper macro for kfree_rcu() to prevent argument-expansion eyestrain.
*/
-#define __kfree_rcu(head, offset) \
+#define __kvfree_rcu(head, offset) \
do { \
BUILD_BUG_ON(!__is_kvfree_rcu_offset(offset)); \
- kfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \
+ kvfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \
} while (0)
/**
@@ -827,7 +827,7 @@ static inline notrace void rcu_read_unlock_sched_notrace(void)
* Because the functions are not allowed in the low-order 4096 bytes of
* kernel virtual memory, offsets up to 4095 bytes can be accommodated.
* If the offset is larger than 4095 bytes, a compile-time error will
- * be generated in __kfree_rcu(). If this error is triggered, you can
+ * be generated in __kvfree_rcu(). If this error is triggered, you can
* either fall back to use of call_rcu() or rearrange the structure to
* position the rcu_head structure into the first 4096 bytes.
*
@@ -842,7 +842,7 @@ do { \
typeof (ptr) ___p = (ptr); \
\
if (___p) \
- __kfree_rcu(&((___p)->rhf), offsetof(typeof(*(ptr)), rhf)); \
+ __kvfree_rcu(&((___p)->rhf), offsetof(typeof(*(ptr)), rhf)); \
} while (0)
/**
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index 045c28b71f4f..4cae3dd77173 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -34,7 +34,7 @@ static inline void synchronize_rcu_expedited(void)
synchronize_rcu();
}
-static inline void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
+static inline void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
{
call_rcu(head, func);
}
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 45f3f66bb04d..3a7829d69fef 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -33,7 +33,7 @@ static inline void rcu_virt_note_context_switch(int cpu)
}
void synchronize_rcu_expedited(void);
-void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func);
+void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func);
void rcu_barrier(void);
bool rcu_eqs_special_set(int cpu);
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index bb9544238396..19e6cb970c38 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3054,18 +3054,18 @@ kfree_call_rcu_add_ptr_to_bulk(struct kfree_rcu_cpu *krcp,
}
/*
- * Queue a request for lazy invocation of kfree_bulk()/kfree() after a grace
+ * Queue a request for lazy invocation of kfree_bulk()/kvfree() after a grace
* period. Please note there are two paths are maintained, one is the main one
* that uses kfree_bulk() interface and second one is emergency one, that is
* used only when the main path can not be maintained temporary, due to memory
* pressure.
*
- * Each kfree_call_rcu() request is added to a batch. The batch will be drained
+ * Each kvfree_call_rcu() request is added to a batch. The batch will be drained
* every KFREE_DRAIN_JIFFIES number of jiffies. All the objects in the batch will
* be free'd in workqueue context. This allows us to: batch requests together to
* reduce the number of grace periods during heavy kfree_rcu() load.
*/
-void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
+void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
{
unsigned long flags;
struct kfree_rcu_cpu *krcp;
@@ -3112,7 +3112,7 @@ void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
spin_unlock(&krcp->lock);
local_irq_restore(flags);
}
-EXPORT_SYMBOL_GPL(kfree_call_rcu);
+EXPORT_SYMBOL_GPL(kvfree_call_rcu);
void __init kfree_rcu_scheduler_running(void)
{
--
2.20.1
On Sun, Mar 15, 2020 at 07:18:39PM +0100, Uladzislau Rezki (Sony) wrote:
> Rename kfree_call_rcu() to the kvfree_call_rcu().
> The reason is, it is capable of freeing vmalloc()
> memory now.
>
> Do the same with __kfree_rcu() macro, it becomes
> __kvfree_rcu(), the reason is the same as pointed
> above.
Vlad, this patch does not apply to my branch that I shared with you. Sorry if
I was not clear earlier, could we work on the same branch to avoid conflicts?
I based the kfree_rcu shrinker patches on an 'rcu/kfree' branch in my git
tree: https://github.com/joelagnel/linux-kernel/tree/rcu/kfree
For now I manually applied 5/6. All others applied cleanly.
Updated the tree as I continue to review your patches.
thanks,
- Joel
>
> Signed-off-by: Uladzislau Rezki (Sony) <[email protected]>
> ---
> include/linux/rcupdate.h | 8 ++++----
> include/linux/rcutiny.h | 2 +-
> include/linux/rcutree.h | 2 +-
> kernel/rcu/tree.c | 8 ++++----
> 4 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index e4961631a44f..6c660fa1f551 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -805,10 +805,10 @@ static inline notrace void rcu_read_unlock_sched_notrace(void)
> /*
> * Helper macro for kfree_rcu() to prevent argument-expansion eyestrain.
> */
> -#define __kfree_rcu(head, offset) \
> +#define __kvfree_rcu(head, offset) \
> do { \
> BUILD_BUG_ON(!__is_kvfree_rcu_offset(offset)); \
> - kfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \
> + kvfree_call_rcu(head, (rcu_callback_t)(unsigned long)(offset)); \
> } while (0)
>
> /**
> @@ -827,7 +827,7 @@ static inline notrace void rcu_read_unlock_sched_notrace(void)
> * Because the functions are not allowed in the low-order 4096 bytes of
> * kernel virtual memory, offsets up to 4095 bytes can be accommodated.
> * If the offset is larger than 4095 bytes, a compile-time error will
> - * be generated in __kfree_rcu(). If this error is triggered, you can
> + * be generated in __kvfree_rcu(). If this error is triggered, you can
> * either fall back to use of call_rcu() or rearrange the structure to
> * position the rcu_head structure into the first 4096 bytes.
> *
> @@ -842,7 +842,7 @@ do { \
> typeof (ptr) ___p = (ptr); \
> \
> if (___p) \
> - __kfree_rcu(&((___p)->rhf), offsetof(typeof(*(ptr)), rhf)); \
> + __kvfree_rcu(&((___p)->rhf), offsetof(typeof(*(ptr)), rhf)); \
> } while (0)
>
> /**
> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> index 045c28b71f4f..4cae3dd77173 100644
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -34,7 +34,7 @@ static inline void synchronize_rcu_expedited(void)
> synchronize_rcu();
> }
>
> -static inline void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
> +static inline void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
> {
> call_rcu(head, func);
> }
> diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
> index 45f3f66bb04d..3a7829d69fef 100644
> --- a/include/linux/rcutree.h
> +++ b/include/linux/rcutree.h
> @@ -33,7 +33,7 @@ static inline void rcu_virt_note_context_switch(int cpu)
> }
>
> void synchronize_rcu_expedited(void);
> -void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func);
> +void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func);
>
> void rcu_barrier(void);
> bool rcu_eqs_special_set(int cpu);
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index bb9544238396..19e6cb970c38 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -3054,18 +3054,18 @@ kfree_call_rcu_add_ptr_to_bulk(struct kfree_rcu_cpu *krcp,
> }
>
> /*
> - * Queue a request for lazy invocation of kfree_bulk()/kfree() after a grace
> + * Queue a request for lazy invocation of kfree_bulk()/kvfree() after a grace
> * period. Please note there are two paths are maintained, one is the main one
> * that uses kfree_bulk() interface and second one is emergency one, that is
> * used only when the main path can not be maintained temporary, due to memory
> * pressure.
> *
> - * Each kfree_call_rcu() request is added to a batch. The batch will be drained
> + * Each kvfree_call_rcu() request is added to a batch. The batch will be drained
> * every KFREE_DRAIN_JIFFIES number of jiffies. All the objects in the batch will
> * be free'd in workqueue context. This allows us to: batch requests together to
> * reduce the number of grace periods during heavy kfree_rcu() load.
> */
> -void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
> +void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
> {
> unsigned long flags;
> struct kfree_rcu_cpu *krcp;
> @@ -3112,7 +3112,7 @@ void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
> spin_unlock(&krcp->lock);
> local_irq_restore(flags);
> }
> -EXPORT_SYMBOL_GPL(kfree_call_rcu);
> +EXPORT_SYMBOL_GPL(kvfree_call_rcu);
>
> void __init kfree_rcu_scheduler_running(void)
> {
> --
> 2.20.1
>
On Mon, Mar 16, 2020 at 11:25:41AM -0400, Joel Fernandes wrote:
> On Sun, Mar 15, 2020 at 07:18:39PM +0100, Uladzislau Rezki (Sony) wrote:
> > Rename kfree_call_rcu() to the kvfree_call_rcu().
> > The reason is, it is capable of freeing vmalloc()
> > memory now.
> >
> > Do the same with __kfree_rcu() macro, it becomes
> > __kvfree_rcu(), the reason is the same as pointed
> > above.
>
> Vlad, this patch does not apply to my branch that I shared with you. Sorry if
> I was not clear earlier, could we work on the same branch to avoid conflicts?
>
It was clear to me. Basically i knew that you would be able to apply it
because of slim changes. I based my work on latest Paul's branch simply
because that my current setup was based on that, it would take more time
to switch.
Next changes i will base on your branch.
> I based the kfree_rcu shrinker patches on an 'rcu/kfree' branch in my git
> tree: https://github.com/joelagnel/linux-kernel/tree/rcu/kfree
>
> For now I manually applied 5/6. All others applied cleanly.
>
> Updated the tree as I continue to review your patches.
>
Thanks!
--
Vlad Rezki
On Mon, 16 Mar 2020 20:01:44 +0100 Uladzislau Rezki <[email protected]> wrote:
> On Mon, Mar 16, 2020 at 11:25:41AM -0400, Joel Fernandes wrote:
> > On Sun, Mar 15, 2020 at 07:18:39PM +0100, Uladzislau Rezki (Sony) wrote:
> > > Rename kfree_call_rcu() to the kvfree_call_rcu().
> > > The reason is, it is capable of freeing vmalloc()
> > > memory now.
> > >
> > > Do the same with __kfree_rcu() macro, it becomes
> > > __kvfree_rcu(), the reason is the same as pointed
> > > above.
> >
> > Vlad, this patch does not apply to my branch that I shared with you. Sorry if
> > I was not clear earlier, could we work on the same branch to avoid conflicts?
> >
> It was clear to me. Basically i knew that you would be able to apply it
> because of slim changes. I based my work on latest Paul's branch simply
> because that my current setup was based on that, it would take more time
> to switch.
>
> Next changes i will base on your branch.
>
> > I based the kfree_rcu shrinker patches on an 'rcu/kfree' branch in my git
> > tree: https://github.com/joelagnel/linux-kernel/tree/rcu/kfree
> >
> > For now I manually applied 5/6. All others applied cleanly.
> >
> > Updated the tree as I continue to review your patches.
> >
I'm not sure what's happening here - these patches aren't yet in
linux-next.
A couple of thoughts:
- Please cc [email protected] on this patchset and anything else
which impacts MM.
- It's a bit strange to create new infrastructure which has but a
single call site. Please tell us much more about "there was also
request/interest so there will be new comers" to set minds at ease.
Who/where are these possible new callsites and when can we expect to
see that code?
Hello, Andrew.
> > > I based the kfree_rcu shrinker patches on an 'rcu/kfree' branch in my git
> > > tree: https://github.com/joelagnel/linux-kernel/tree/rcu/kfree
> > >
> > > For now I manually applied 5/6. All others applied cleanly.
> > >
> > > Updated the tree as I continue to review your patches.
> > >
>
> I'm not sure what's happening here - these patches aren't yet in
> linux-next.
>
Please have a look here, i explained in detail in my cover latter
what we would like to achieve: https://lkml.org/lkml/2020/3/23/242
> A couple of thoughts:
>
> - Please cc [email protected] on this patchset and anything else
> which impacts MM.
>
OK. I thought that is related to RCU, therefore i did not want to
spam, but i included you :) Next time we will keep [email protected]
in a loop. Sorry for that.
>
> - It's a bit strange to create new infrastructure which has but a
> single call site. Please tell us much more about "there was also
> request/interest so there will be new comers" to set minds at ease.
>
> Who/where are these possible new callsites and when can we expect to
> see that code?
>
https://lkml.org/lkml/2020/3/23/242 here i wrote motivation. Please
check it. If you have some questions please ask.
--
Vlad Rezki
On Tue, Apr 21, 2020 at 02:03:58PM +0200, Uladzislau Rezki wrote:
> Hello, Andrew.
>
> > > > I based the kfree_rcu shrinker patches on an 'rcu/kfree' branch in my git
> > > > tree: https://github.com/joelagnel/linux-kernel/tree/rcu/kfree
> > > >
> > > > For now I manually applied 5/6. All others applied cleanly.
> > > >
> > > > Updated the tree as I continue to review your patches.
> > > >
> >
> > I'm not sure what's happening here - these patches aren't yet in
> > linux-next.
> >
> Please have a look here, i explained in detail in my cover latter
> what we would like to achieve: https://lkml.org/lkml/2020/3/23/242
>
> > A couple of thoughts:
> >
> > - Please cc [email protected] on this patchset and anything else
> > which impacts MM.
> >
> OK. I thought that is related to RCU, therefore i did not want to
> spam, but i included you :) Next time we will keep [email protected]
> in a loop. Sorry for that.
Sorry from my side as well. Will keep linux-mm in the loop henceforth.
thanks,
- Joel
>
> >
> > - It's a bit strange to create new infrastructure which has but a
> > single call site. Please tell us much more about "there was also
> > request/interest so there will be new comers" to set minds at ease.
> >
> > Who/where are these possible new callsites and when can we expect to
> > see that code?
> >
> https://lkml.org/lkml/2020/3/23/242 here i wrote motivation. Please
> check it. If you have some questions please ask.
>
> --
> Vlad Rezki
On Wed, Apr 22, 2020 at 07:03:22PM -0400, Joel Fernandes wrote:
> On Tue, Apr 21, 2020 at 02:03:58PM +0200, Uladzislau Rezki wrote:
> > Hello, Andrew.
> >
> > > > > I based the kfree_rcu shrinker patches on an 'rcu/kfree' branch in my git
> > > > > tree: https://github.com/joelagnel/linux-kernel/tree/rcu/kfree
> > > > >
> > > > > For now I manually applied 5/6. All others applied cleanly.
> > > > >
> > > > > Updated the tree as I continue to review your patches.
> > > > >
> > >
> > > I'm not sure what's happening here - these patches aren't yet in
> > > linux-next.
> > >
> > Please have a look here, i explained in detail in my cover latter
> > what we would like to achieve: https://lkml.org/lkml/2020/3/23/242
> >
> > > A couple of thoughts:
> > >
> > > - Please cc [email protected] on this patchset and anything else
> > > which impacts MM.
> > >
> > OK. I thought that is related to RCU, therefore i did not want to
> > spam, but i included you :) Next time we will keep [email protected]
> > in a loop. Sorry for that.
>
> Sorry from my side as well. Will keep linux-mm in the loop henceforth.
I must confess that it came as a bit of a surprise to me as well.
But what is life without a surprise or two along the way? ;-)
Thanx, Paul
> thanks,
>
> - Joel
>
>
> >
> > >
> > > - It's a bit strange to create new infrastructure which has but a
> > > single call site. Please tell us much more about "there was also
> > > request/interest so there will be new comers" to set minds at ease.
> > >
> > > Who/where are these possible new callsites and when can we expect to
> > > see that code?
> > >
> > https://lkml.org/lkml/2020/3/23/242 here i wrote motivation. Please
> > check it. If you have some questions please ask.
> >
> > --
> > Vlad Rezki