Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1501295 > unrolled thread
| Started by | <zhouxianrong@huawei.com> |
|---|---|
| First post | 2016-10-15 16:30 +0200 |
| Last post | 2016-10-18 04:30 +0200 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH vmalloc] reduce purge_lock range and hold time of <zhouxianrong@huawei.com> - 2016-10-15 16:30 +0200
Re: [PATCH vmalloc] reduce purge_lock range and hold time of Christoph Hellwig <hch@infradead.org> - 2016-10-15 19:00 +0200
Re: [PATCH vmalloc] reduce purge_lock range and hold time of zhouxianrong <zhouxianrong@huawei.com> - 2016-10-18 05:00 +0200
[PATCH vmalloc] reduce purge_lock range and hold time of vmap_area_lock <zhouxianrong@huawei.com> - 2016-10-18 04:30 +0200
| From | <zhouxianrong@huawei.com> |
|---|---|
| Date | 2016-10-15 16:30 +0200 |
| Subject | [PATCH vmalloc] reduce purge_lock range and hold time of |
| Message-ID | <ssy8i-nb-5@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Christoph Hellwig <hch@infradead.org> |
|---|---|
| Date | 2016-10-15 19:00 +0200 |
| Message-ID | <ssAtr-1OK-9@gated-at.bofh.it> |
| In reply to | #1501295 |
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.
[toc] | [prev] | [next] | [standalone]
| From | zhouxianrong <zhouxianrong@huawei.com> |
|---|---|
| Date | 2016-10-18 05:00 +0200 |
| Message-ID | <stsNc-4eA-9@gated-at.bofh.it> |
| In reply to | #1501327 |
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. > > . >
[toc] | [prev] | [next] | [standalone]
| From | <zhouxianrong@huawei.com> |
|---|---|
| Date | 2016-10-18 04:30 +0200 |
| Subject | [PATCH vmalloc] reduce purge_lock range and hold time of vmap_area_lock |
| Message-ID | <stsk9-44G-5@gated-at.bofh.it> |
| In reply to | #1501295 |
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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web