[PATCH vmalloc] reduce purge_lock range and hold time of

[PATCH vmalloc] reduce purge_lock range and hold time of

[zhouxianrong]

From: z00281421 <z00281421@notesmail.huawei.com>

i think no need to place __free_vmap_area loop in purge_lock;
_free_vmap_area could be non-atomic operations with flushing tlb
but must be done after flush tlb. and the whole__free_vmap_area loops
also could be non-atomic operations. if so we could improve realtime
because the loop times sometimes is larg and spend a few time.

Signed-off-by: z00281421 <z00281421@notesmail.huawei.com>
---
 mm/vmalloc.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 91f44e7..9d9154d 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -661,13 +661,23 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
 	if (nr || force_flush)
 		flush_tlb_kernel_range(*start, *end);
 
+	spin_unlock(&purge_lock);
+
 	if (nr) {
+		/* the batch count should not be too small
+		** because if vmalloc space is few free is first than alloc.
+		*/
+		unsigned char batch = -1;
 		spin_lock(&vmap_area_lock);
-		llist_for_each_entry_safe(va, n_va, valist, purge_list)
+		llist_for_each_entry_safe(va, n_va, valist, purge_list) {
 			__free_vmap_area(va);
+			if (!batch--) {
+				spin_unlock(&vmap_area_lock);
+				spin_lock(&vmap_area_lock);
+			}
+		}
 		spin_unlock(&vmap_area_lock);
 	}
-	spin_unlock(&purge_lock);
 }
 
 /*
-- 
1.7.9.5

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH vmalloc] reduce purge_lock range and hold time of

[Christoph Hellwig]

On Sat, Oct 15, 2016 at 10:12:48PM +0800, zhouxianrong@huawei.com wrote:
> From: z00281421 <z00281421@notesmail.huawei.com>
> 
> i think no need to place __free_vmap_area loop in purge_lock;
> _free_vmap_area could be non-atomic operations with flushing tlb
> but must be done after flush tlb. and the whole__free_vmap_area loops
> also could be non-atomic operations. if so we could improve realtime
> because the loop times sometimes is larg and spend a few time.

Right, see the previous patch in reply to Joel that drops purge_lock
entirely.

Instead of your open coded batch counter you probably want to add
a cond_resched_lock after the call to __free_vmap_area.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH vmalloc] reduce purge_lock range and hold time of vmap_area_lock

[zhouxianrong]

From: z00281421 <z00281421@notesmail.huawei.com>


Signed-off-by: z00281421 <z00281421@notesmail.huawei.com>
---
 mm/vmalloc.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 91f44e7..e9c9c04 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -661,13 +661,18 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
 	if (nr || force_flush)
 		flush_tlb_kernel_range(*start, *end);
 
+	spin_unlock(&purge_lock);
+
 	if (nr) {
+		unsigned char batch = 0;
 		spin_lock(&vmap_area_lock);
-		llist_for_each_entry_safe(va, n_va, valist, purge_list)
+		llist_for_each_entry_safe(va, n_va, valist, purge_list) {
 			__free_vmap_area(va);
+			if (!batch++)
+				cond_resched_lock(&vmap_area_lock);
+		}
 		spin_unlock(&vmap_area_lock);
 	}
-	spin_unlock(&purge_lock);
 }
 
 /*
-- 
1.7.9.5

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH vmalloc] reduce purge_lock range and hold time of

[zhouxianrong]

hey Hellwig:
	cond_resched_lock is a good choice. i mixed the cond_resched_lock and batch to balance of
realtime and performance and resubmit this patch.

On 2016/10/16 0:55, Christoph Hellwig wrote:
> On Sat, Oct 15, 2016 at 10:12:48PM +0800, zhouxianrong@huawei.com wrote:
>> From: z00281421 <z00281421@notesmail.huawei.com>
>>
>> i think no need to place __free_vmap_area loop in purge_lock;
>> _free_vmap_area could be non-atomic operations with flushing tlb
>> but must be done after flush tlb. and the whole__free_vmap_area loops
>> also could be non-atomic operations. if so we could improve realtime
>> because the loop times sometimes is larg and spend a few time.
>
> Right, see the previous patch in reply to Joel that drops purge_lock
> entirely.
>
> Instead of your open coded batch counter you probably want to add
> a cond_resched_lock after the call to __free_vmap_area.
>
> .
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>