search for: gfp_noio

...attitude from Michal again and again. Fine; then *say that*. I also see Michal saying "No" a lot. Sometimes I agree with him, sometimes I don't. I think he genuinely wants the best code in the kernel, and saying "No" is part of it. > He didn't want to fix vmalloc(GFP_NOIO) I don't remember that conversation, so I don't know whether 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 didn't want...

...attitude from Michal again and again. Fine; then *say that*. I also see Michal saying "No" a lot. Sometimes I agree with him, sometimes I don't. I think he genuinely wants the best code in the kernel, and saying "No" is part of it. > He didn't want to fix vmalloc(GFP_NOIO) I don't remember that conversation, so I don't know whether 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 didn't want...

...ine; then *say that*. I also see Michal saying "No" a lot. Sometimes > > I agree with him, sometimes I don't. I think he genuinely wants the best > > code in the kernel, and saying "No" is part of it. > > > > > He didn't want to fix vmalloc(GFP_NOIO) > > > > I don't remember that conversation, so I don't know whether 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...

...ine; then *say that*. I also see Michal saying "No" a lot. Sometimes > > I agree with him, sometimes I don't. I think he genuinely wants the best > > code in the kernel, and saying "No" is part of it. > > > > > He didn't want to fix vmalloc(GFP_NOIO) > > > > I don't remember that conversation, so I don't know whether 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...

On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > On Mon, 23 Apr 2018, Michal Hocko wrote: > > > On Mon 23-04-18 10:06:08, Mikulas Patocka wrote: > > > > > > > He didn't want to fix vmalloc(GFP_NOIO) > > > > > > > > I don't remember that conversation, so I don't know whether 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....

On Mon 23-04-18 20:25:15, Mikulas Patocka wrote: > > > On Mon, 23 Apr 2018, Michal Hocko wrote: > > > On Mon 23-04-18 10:06:08, Mikulas Patocka wrote: > > > > > > > He didn't want to fix vmalloc(GFP_NOIO) > > > > > > > > I don't remember that conversation, so I don't know whether 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....

On Mon, 23 Apr 2018, Michal Hocko wrote: > On Mon 23-04-18 10:06:08, Mikulas Patocka wrote: > > > > > He didn't want to fix vmalloc(GFP_NOIO) > > > > > > I don't remember that conversation, so I don't know whether 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 > >...

...again. > > Fine; then *say that*. I also see Michal saying "No" a lot. Sometimes > I agree with him, sometimes I don't. I think he genuinely wants the best > code in the kernel, and saying "No" is part of it. > > > He didn't want to fix vmalloc(GFP_NOIO) > > I don't remember that conversation, so I don't know whether 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)....

On Sun, 22 Apr 2018, Michal Hocko wrote: > On Sat 21-04-18 07:47:57, Matthew Wilcox wrote: > > > > He didn't want to fix vmalloc(GFP_NOIO) > > > > I don't remember that conversation, so I don't know whether 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...

On Sun, 22 Apr 2018, Michal Hocko wrote: > On Sat 21-04-18 07:47:57, Matthew Wilcox wrote: > > > > He didn't want to fix vmalloc(GFP_NOIO) > > > > I don't remember that conversation, so I don't know whether 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...

...; > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be > > enabled quite often. > > You're an evil person who doesn't want to fix bugs. Steady on. There's no need for that. Michal isn't evil. Please apologise. > You refused to fix vmalloc(GFP_NOIO) misbehavior a year ago (did you make > some progress with it since that time?) and you refuse to fix kvmalloc > misuses. I understand you're frustrated, but this is not the way to get the problems fixed. > I tried this patch on text-only virtual machine and /proc/vmallocinfo >...

...; > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be > > enabled quite often. > > You're an evil person who doesn't want to fix bugs. Steady on. There's no need for that. Michal isn't evil. Please apologise. > You refused to fix vmalloc(GFP_NOIO) misbehavior a year ago (did you make > some progress with it since that time?) and you refuse to fix kvmalloc > misuses. I understand you're frustrated, but this is not the way to get the problems fixed. > I tried this patch on text-only virtual machine and /proc/vmallocinfo >...

...n might recurse into your driver? > Right. We can't (directly or indirectly) depend on __GFP_DIRECT_RECLAIM && !__GFP_NORETRY > allocations because the balloon driver needs to handle OOM notifier callback. > >> Would GFP_NOIO >> do the job? I'm a little hazy on exactly how the balloon driver works. > GFP_NOIO implies __GFP_DIRECT_RECLAIM. In the worst case, it can lockup due to > the too small to fail memory allocation rule. GFP_NOIO | __GFP_NORETRY would work > if there is really a guarantee that GF...

...;No" is part of it. Exactly! We have a lot of legacy herritage and random semantic because we were too eager to merge stuff. I think it is time to stop that and think twice before merging someothing. If you call that evil then I am fine to be evil. > > He didn't want to fix vmalloc(GFP_NOIO) > > I don't remember that conversation, so I don't know whether 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)....

...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 alows maintainers to not care about their broken code. Most maintainers don't even know that it's broken. Out of 14 subsystems using __vmalloc with GFP_NOIO/NOFS, only 2 realized that its implementation is broken and implemented a workaround (me and the XFS developers). Misimplementing a function in a subtle and hard-to-notice way won't drive developers away from using it. > > > > He refuses 15-line patch to fix GFP_NOIO bug becaus...

Hello Andrew, I fetched (CVS) ext3 latest changes (3 July 2001) which include changing GFP_BUFFER to GFP_NOFS and now have random troubles with symlink files on ext3 filesystems. >From my experience over the last days with Linus's changes I find that GFP_NOIO worked perfectly. Below is Linus's response about bounce buffer change. I am late to work, but this evening will try to substitute _NOFS for _NOIO and report back results. Later, Albert > Subject: > Re: Bounce buffer deadlock > Date: > Sat, 30 Jun 2001 10:5...

...blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1203,11 +1203,10 @@ static int blkif_recover(struct blkfront_info *info) int j; /* Stage 1: Make a safe copy of the shadow state. */ - copy = kmalloc(sizeof(info->shadow), + copy = kmemdup(info->shadow, sizeof(info->shadow), GFP_NOIO | __GFP_REPEAT | __GFP_HIGH); if (!copy) return -ENOMEM; - memcpy(copy, info->shadow, sizeof(info->shadow)); /* Stage 2: Set up free list. */ memset(&info->shadow, 0, sizeof(info->shadow)); -- 1.7.10.4

...blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1203,11 +1203,10 @@ static int blkif_recover(struct blkfront_info *info) int j; /* Stage 1: Make a safe copy of the shadow state. */ - copy = kmalloc(sizeof(info->shadow), + copy = kmemdup(info->shadow, sizeof(info->shadow), GFP_NOIO | __GFP_REPEAT | __GFP_HIGH); if (!copy) return -ENOMEM; - memcpy(copy, info->shadow, sizeof(info->shadow)); /* Stage 2: Set up free list. */ memset(&info->shadow, 0, sizeof(info->shadow)); -- 1.7.10.4

upstream commit 7e96287ddc4f42081e18248b6167041c0908004c Author: Vivek Goyal <vgoyal@in.ibm.com> [PATCH] kdump: introduce "reset_devices" command line option Resetting the devices during driver initialization can be a costly operation in terms of time (especially scsi devices). This option can be used by drivers to know that user forcibly wants the devices to

.../block/zram/zram_drv.c index 370c2f76016d..10f6ff1cf6a0 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -514,7 +514,8 @@ static struct zram_meta *zram_meta_alloc(char *pool_name, u64 disksize) goto out_error; } - meta->mem_pool = zs_create_pool(pool_name, GFP_NOIO | __GFP_HIGHMEM); + meta->mem_pool = zs_create_pool(pool_name, GFP_NOIO|__GFP_HIGHMEM + |__GFP_MOVABLE); if (!meta->mem_pool) { pr_err("Error creating memory pool\n"); goto out_error; diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index b9ff698115a1..a1f47a7b3a99 100644 ---...