search for: __vmalloc

On Tue 24-04-18 11:30:40, Mikulas Patocka wrote: > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > > > Fixing __vmalloc code > > > is easy and it doesn't require cooperation with maintainers. > > > > But it is a hack against the intention of the scope api. > > It is not! This discussion simply doesn't make much sense it seems. The scope API is to document the scope of the recla...

On Tue 24-04-18 11:30:40, Mikulas Patocka wrote: > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > > > Fixing __vmalloc code > > > is easy and it doesn't require cooperation with maintainers. > > > > But it is a hack against the intention of the scope api. > > It is not! This discussion simply doesn't make much sense it seems. The scope API is to document the scope of the recla...

...away from GFP_NOIO > > > > towards marking regions with memalloc_noio_save() / restore. If you do > > > > that, you won't need vmalloc(GFP_NOIO). > > > > > > He said the same thing a year ago. And there was small progress. 6 out of > > > 27 __vmalloc calls were converted to memalloc_noio_save in a year - 5 in > > > infiniband and 1 in btrfs. (the whole discussion is here > > > http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04681.html ) > > > > Well this is not that easy. It requires a cooperation from maintain...

...away from GFP_NOIO > > > > towards marking regions with memalloc_noio_save() / restore. If you do > > > > that, you won't need vmalloc(GFP_NOIO). > > > > > > He said the same thing a year ago. And there was small progress. 6 out of > > > 27 __vmalloc calls were converted to memalloc_noio_save in a year - 5 in > > > infiniband and 1 in btrfs. (the whole discussion is here > > > http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04681.html ) > > > > Well this is not that easy. It requires a cooperation from maintain...

...o wrote: > > > On Tue 24-04-18 11:30:40, Mikulas Patocka wrote: > > > > > > > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > > > > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > > > > > > > Fixing __vmalloc code > > > > > is easy and it doesn't require cooperation with maintainers. > > > > > > > > But it is a hack against the intention of the scope api. > > > > > > It is not! > > > > This discussion simply doesn't make mu...

On Tue, 24 Apr 2018, Michal Hocko wrote: > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > Fixing __vmalloc code > > is easy and it doesn't require cooperation with maintainers. > > But it is a hack against the intention of the scope api. It is not! You can fix __vmalloc now and you can convert the kernel to the scope API in 4 years. It's not one way or the other. > It also al...

...ging/hv/hv.c index 021acba..419b4d6 100644 --- a/drivers/staging/hv/hv.c +++ b/drivers/staging/hv/hv.c @@ -230,7 +230,12 @@ int hv_init(void) * Allocate the hypercall page memory * virtaddr = osd_page_alloc(1); */ - virtaddr = osd_virtual_alloc_exec(PAGE_SIZE); +#ifdef __x86_64__ + virtaddr = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_EXEC); +#else + virtaddr = __vmalloc(PAGE_SIZE, GFP_KERNEL, + __pgprot(__PAGE_KERNEL & (~_PAGE_NX))); +#endif if (!virtaddr) { DPRINT_ERR(VMBUS, @@ -462,10 +467,10 @@ void hv_synic_init(void *irqarg) Cleanup: if (hv_context.synic_event_page[cpu]...

...ging/hv/hv.c index 021acba..419b4d6 100644 --- a/drivers/staging/hv/hv.c +++ b/drivers/staging/hv/hv.c @@ -230,7 +230,12 @@ int hv_init(void) * Allocate the hypercall page memory * virtaddr = osd_page_alloc(1); */ - virtaddr = osd_virtual_alloc_exec(PAGE_SIZE); +#ifdef __x86_64__ + virtaddr = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_EXEC); +#else + virtaddr = __vmalloc(PAGE_SIZE, GFP_KERNEL, + __pgprot(__PAGE_KERNEL & (~_PAGE_NX))); +#endif if (!virtaddr) { DPRINT_ERR(VMBUS, @@ -462,10 +467,10 @@ void hv_synic_init(void *irqarg) Cleanup: if (hv_context.synic_event_page[cpu]...

...easoning or not. But we are supposed to be moving away from GFP_NOIO > > towards marking regions with memalloc_noio_save() / restore. If you do > > that, you won't need vmalloc(GFP_NOIO). > > He said the same thing a year ago. And there was small progress. 6 out of > 27 __vmalloc calls were converted to memalloc_noio_save in a year - 5 in > infiniband and 1 in btrfs. (the whole discussion is here > http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04681.html ) Well this is not that easy. It requires a cooperation from maintainers. I can only do as much. I've pos...

...easoning or not. But we are supposed to be moving away from GFP_NOIO > > towards marking regions with memalloc_noio_save() / restore. If you do > > that, you won't need vmalloc(GFP_NOIO). > > He said the same thing a year ago. And there was small progress. 6 out of > 27 __vmalloc calls were converted to memalloc_noio_save in a year - 5 in > infiniband and 1 in btrfs. (the whole discussion is here > http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04681.html ) Well this is not that easy. It requires a cooperation from maintainers. I can only do as much. I've pos...

Previous 2.6.31-rc8 kernel was built on F11 and installed with modules on F12. Current kernel has been built on F12 (2.6.31-0.204.rc9.fc12.x86_64) and installed on F12 before loading under Xen 3.4.1. Dmesg log looks similar to Michael Yuong''s ''rc7.git4''  kernel for F12. Boris. --- On Tue, 9/8/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris

...are supposed to be moving away from GFP_NOIO > > > towards marking regions with memalloc_noio_save() / restore. If you do > > > that, you won't need vmalloc(GFP_NOIO). > > > > He said the same thing a year ago. And there was small progress. 6 out of > > 27 __vmalloc calls were converted to memalloc_noio_save in a year - 5 in > > infiniband and 1 in btrfs. (the whole discussion is here > > http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04681.html ) > > Well this is not that easy. It requires a cooperation from maintainers. > I can only...

On Tue, 24 Apr 2018, Michal Hocko wrote: > On Tue 24-04-18 11:30:40, Mikulas Patocka wrote: > > > > > > On Tue, 24 Apr 2018, Michal Hocko wrote: > > > > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > > > > > Fixing __vmalloc code > > > > is easy and it doesn't require cooperation with maintainers. > > > > > > But it is a hack against the intention of the scope api. > > > > It is not! > > This discussion simply doesn't make much sense it seems. The scope API &g...

...ff --git a/drivers/staging/hv/hv.c b/drivers/staging/hv/hv.c index 31b9073..2d492ad 100644 --- a/drivers/staging/hv/hv.c +++ b/drivers/staging/hv/hv.c @@ -230,12 +230,7 @@ int hv_init(void) * Allocate the hypercall page memory * virtaddr = osd_page_alloc(1); */ -#ifdef __x86_64__ virtaddr = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_EXEC); -#else - virtaddr = __vmalloc(PAGE_SIZE, GFP_KERNEL, - __pgprot(__PAGE_KERNEL & (~_PAGE_NX))); -#endif if (!virtaddr) { DPRINT_ERR(VMBUS, -- 1.5.5.6

...ff --git a/drivers/staging/hv/hv.c b/drivers/staging/hv/hv.c index 31b9073..2d492ad 100644 --- a/drivers/staging/hv/hv.c +++ b/drivers/staging/hv/hv.c @@ -230,12 +230,7 @@ int hv_init(void) * Allocate the hypercall page memory * virtaddr = osd_page_alloc(1); */ -#ifdef __x86_64__ virtaddr = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_EXEC); -#else - virtaddr = __vmalloc(PAGE_SIZE, GFP_KERNEL, - __pgprot(__PAGE_KERNEL & (~_PAGE_NX))); -#endif if (!virtaddr) { DPRINT_ERR(VMBUS, -- 1.5.5.6

...t;ffffffff8020b22d>] xen_alloc_ptpage+0x8d/0xa0 [ 0.010000] [<ffffffff8020b293>] xen_alloc_pte+0x13/0x20 [ 0.010000] [<ffffffff802bef21>] __pte_alloc_kernel+0x61/0xc0 [ 0.010000] [<ffffffff802cbdf4>] map_vm_area+0x2d4/0x350 [ 0.010000] [<ffffffff802cc5f0>] __vmalloc_area_node+0x140/0x1a0 [ 0.010000] [<ffffffff80740856>] ? alloc_large_system_hash+0x24c/0x2b0 [ 0.010000] [<ffffffff802cc6f1>] __vmalloc_node+0xa1/0xb0 [ 0.010000] [<ffffffff80740856>] ? alloc_large_system_hash+0x24c/0x2b0 [ 0.010000] [<ffffffff80740856>] ? al...

...r I agree with > his reasoning or not. But we are supposed to be moving away from GFP_NOIO > towards marking regions with memalloc_noio_save() / restore. If you do > that, you won't need vmalloc(GFP_NOIO). He said the same thing a year ago. And there was small progress. 6 out of 27 __vmalloc calls were converted to memalloc_noio_save in a year - 5 in infiniband and 1 in btrfs. (the whole discussion is here http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04681.html ) He refuses 15-line patch to fix GFP_NOIO bug because he believes that in 4 years, the kernel will be refactored and...

...gt;] [<c01075d4>] <4> [<c01074e3>] <4>Code: 0f 0b 68 04 cd 43 24 c0 89 7c 24 04 81 64 24 04 f0 01 00 00 >>EIP; c012da44 <kmem_cache_grow+54/240> <===== Trace; c012e080 <kmalloc+150/180> Trace; c012cb07 <get_vm_area+17/100> Trace; c012ccde <__vmalloc+3e/200> Trace; d095d90d <[iptable_filter].data.end+3fae/56a1> Trace; d0931a45 <[ip_conntrack]__unexpect_related+5/60> Trace; d0932315 <[ip_conntrack]icmp_error_track+d5/1a0> Trace; c01305bf <__alloc_pages+3f/170> Trace; d09327f7 <[ip_conntrack]init_conntrack+2a7/390&gt...

On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote: > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote: > > > On Fri, 20 Apr 2018, Michal Hocko wrote: > > > > No way. This is just wrong! First of all, you will explode most likely > > > > on many allocations of small sizes. Second,

On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote: > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote: > > > On Fri, 20 Apr 2018, Michal Hocko wrote: > > > > No way. This is just wrong! First of all, you will explode most likely > > > > on many allocations of small sizes. Second,