The read_from_bdev_async is not called on atomic context. So GFP_NOIO is
available rather than GFP_ATOMIC. If there were reclaimable pages with
GFP_NOIO, we can avoid allocation failure and page fault failure.
Reported-by: Yong-Taek Lee <[email protected]>
Signed-off-by: Jaewon Kim <[email protected]>
---
drivers/block/zram/zram_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index fcaf2750f68f..53be528a39a2 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -587,7 +587,7 @@ static int read_from_bdev_async(struct zram *zram, struct bio_vec *bvec,
{
struct bio *bio;
- bio = bio_alloc(GFP_ATOMIC, 1);
+ bio = bio_alloc(GFP_NOIO|__GFP_HIGHMEM, 1);
if (!bio)
return -ENOMEM;
--
2.17.1
On Mon, Sep 06, 2021 at 02:29:26PM +0900, Jaewon Kim wrote:
> The read_from_bdev_async is not called on atomic context. So GFP_NOIO is
> available rather than GFP_ATOMIC. If there were reclaimable pages with
> GFP_NOIO, we can avoid allocation failure and page fault failure.
>
> Reported-by: Yong-Taek Lee <[email protected]>
> Signed-off-by: Jaewon Kim <[email protected]>
> ---
> drivers/block/zram/zram_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index fcaf2750f68f..53be528a39a2 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -587,7 +587,7 @@ static int read_from_bdev_async(struct zram *zram, struct bio_vec *bvec,
> {
> struct bio *bio;
>
> - bio = bio_alloc(GFP_ATOMIC, 1);
> + bio = bio_alloc(GFP_NOIO|__GFP_HIGHMEM, 1);
Passing __GFP_HIGHMEM to bio_alloc does not make any sense whatsoever.
>
>
>--------- Original Message ---------
>Sender : Christoph Hellwig <[email protected]>
>Date : 2021-09-06 17:39 (GMT+9)
>Title : Re: [PATCH] zram_drv: allow reclaim on bio_alloc
>
>On Mon, Sep 06, 2021 at 02:29:26PM +0900, Jaewon Kim wrote:
>> The read_from_bdev_async is not called on atomic context. So GFP_NOIO is
>> available rather than GFP_ATOMIC. If there were reclaimable pages with
>> GFP_NOIO, we can avoid allocation failure and page fault failure.
>>
>> Reported-by: Yong-Taek Lee <[email protected]>
>> Signed-off-by: Jaewon Kim <[email protected]>
>> ---
>> drivers/block/zram/zram_drv.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
>> index fcaf2750f68f..53be528a39a2 100644
>> --- a/drivers/block/zram/zram_drv.c
>> +++ b/drivers/block/zram/zram_drv.c
>> @@ -587,7 +587,7 @@ static int read_from_bdev_async(struct zram *zram, struct bio_vec *bvec,
>> {
>> struct bio *bio;
>>
>> - bio = bio_alloc(GFP_ATOMIC, 1);
>> + bio = bio_alloc(GFP_NOIO|__GFP_HIGHMEM, 1);
>
>Passing __GFP_HIGHMEM to bio_alloc does not make any sense whatsoever.
>
Correct, let me remove __GFP_HIGHMEM if I send v2 patch.
Thank you
Hi Jaewon,
On Mon, Sep 06, 2021 at 06:14:48PM +0900, Jaewon Kim wrote:
> >
> >
> >--------- Original Message ---------
> >Sender : Christoph Hellwig <[email protected]>
> >Date : 2021-09-06 17:39 (GMT+9)
> >Title : Re: [PATCH] zram_drv: allow reclaim on bio_alloc
> >
> >On Mon, Sep 06, 2021 at 02:29:26PM +0900, Jaewon Kim wrote:
> >> The read_from_bdev_async is not called on atomic context. So GFP_NOIO is
> >> available rather than GFP_ATOMIC. If there were reclaimable pages with
> >> GFP_NOIO, we can avoid allocation failure and page fault failure.
> >>
> >> Reported-by: Yong-Taek Lee <[email protected]>
> >> Signed-off-by: Jaewon Kim <[email protected]>
Looks reasonable to me.
Feel free to add after dealing with Christoph's comment.
Acked-by: Minchan Kim <[email protected]>
Thank you.
> >> ---
> >> drivers/block/zram/zram_drv.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> >> index fcaf2750f68f..53be528a39a2 100644
> >> --- a/drivers/block/zram/zram_drv.c
> >> +++ b/drivers/block/zram/zram_drv.c
> >> @@ -587,7 +587,7 @@ static int read_from_bdev_async(struct zram *zram, struct bio_vec *bvec,
> >> {
> >> struct bio *bio;
> >>
> >> - bio = bio_alloc(GFP_ATOMIC, 1);
> >> + bio = bio_alloc(GFP_NOIO|__GFP_HIGHMEM, 1);
> >
> >Passing __GFP_HIGHMEM to bio_alloc does not make any sense whatsoever.
> >
> Correct, let me remove __GFP_HIGHMEM if I send v2 patch.
> Thank you
>
>
>--------- Original Message ---------
>Sender : Minchan Kim <[email protected]>
>Date : 2021-09-08 02:00 (GMT+9)
>Title : Re: (2) [PATCH] zram_drv: allow reclaim on bio_alloc
>
>Hi Jaewon,
>
>On Mon, Sep 06, 2021 at 06:14:48PM +0900, Jaewon Kim wrote:
>> >
>> >
>> >--------- Original Message ---------
>> >Sender : Christoph Hellwig <[email protected]>
>> >Date : 2021-09-06 17:39 (GMT+9)
>> >Title : Re: [PATCH] zram_drv: allow reclaim on bio_alloc
>> >
>> >On Mon, Sep 06, 2021 at 02:29:26PM +0900, Jaewon Kim wrote:
>> >> The read_from_bdev_async is not called on atomic context. So GFP_NOIO is
>> >> available rather than GFP_ATOMIC. If there were reclaimable pages with
>> >> GFP_NOIO, we can avoid allocation failure and page fault failure.
>> >>
>> >> Reported-by: Yong-Taek Lee <[email protected]>
>> >> Signed-off-by: Jaewon Kim <[email protected]>
>
>Looks reasonable to me.
>Feel free to add after dealing with Christoph's comment.
>
>Acked-by: Minchan Kim <[email protected]>
>
>Thank you.
Thank you, I will send v2 patch soon.
>
>> >> ---
>> >> drivers/block/zram/zram_drv.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
>> >> index fcaf2750f68f..53be528a39a2 100644
>> >> --- a/drivers/block/zram/zram_drv.c
>> >> +++ b/drivers/block/zram/zram_drv.c
>> >> @@ -587,7 +587,7 @@ static int read_from_bdev_async(struct zram *zram, struct bio_vec *bvec,
>> >> {
>> >> struct bio *bio;
>> >>
>> >> - bio = bio_alloc(GFP_ATOMIC, 1);
>> >> + bio = bio_alloc(GFP_NOIO|__GFP_HIGHMEM, 1);
>> >
>> >Passing __GFP_HIGHMEM to bio_alloc does not make any sense whatsoever.
>> >
>> Correct, let me remove __GFP_HIGHMEM if I send v2 patch.
>> Thank you
>