All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Efremov <efremov@linux.com>
To: Joe Perches <joe@perches.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: libcxgbi: use kvzalloc instead of opencoded kzalloc/vzalloc
Date: Sat, 1 Aug 2020 10:51:40 +0300	[thread overview]
Message-ID: <c5a18804-3236-9688-2a3c-68184f0dd9e8@linux.com> (raw)
In-Reply-To: <8638183f559c0f8f8d377bd0a6c91903b2c588df.camel@perches.com>



On 8/1/20 1:24 AM, Joe Perches wrote:
> On Sat, 2020-08-01 at 01:10 +0300, Denis Efremov wrote:
>>
>> On 8/1/20 12:58 AM, Joe Perches wrote:
>>> On Sat, 2020-08-01 at 00:55 +0300, Denis Efremov wrote:
>>>> Remove cxgbi_alloc_big_mem(), cxgbi_free_big_mem() functions
>>>> and use kvzalloc/kvfree instead.
>>>
>>> Sensible, thanks.
>>>
>>>> diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
>>> []
>>>> @@ -77,9 +77,9 @@ int cxgbi_device_portmap_create(struct cxgbi_device *cdev, unsigned int base,
>>>>  {
>>>>  	struct cxgbi_ports_map *pmap = &cdev->pmap;
>>>>  
>>>> -	pmap->port_csk = cxgbi_alloc_big_mem(max_conn *
>>>> -					     sizeof(struct cxgbi_sock *),
>>>> -					     GFP_KERNEL);
>>>> +	pmap->port_csk = kvzalloc(array_size(max_conn,
>>>> +					     sizeof(struct cxgbi_sock *)),
>>>> +				  GFP_KERNEL);
>>>
>>> missing __GFP_NOWARN
>>>
>>
>> kvmalloc_node adds __GFP_NOWARN internally to kmalloc call
>> https://elixir.bootlin.com/linux/v5.8-rc4/source/mm/util.c#L568
> 
> Only when there's a fallback, and the fallback does not.
> 

Sorry, Joe, I don't understand why do we need to add __GFP_NOWARN here.

We use GFP_KERNEL for allocation. cxgbi_alloc_big_mem adds __GFP_NOWARN only to kzalloc().
kvzalloc is: kvmalloc(size, flags | __GFP_ZERO)
kvmalloc is: kvmalloc_node(size, flags, NUMA_NO_NODE)
kvmalloc_node: 
	if ((flags & GFP_KERNEL) != GFP_KERNEL)           // false, flags == GFP_KERNEL|__GFP_ZERO
		return kmalloc_node(size, flags, node);

	if (size > PAGE_SIZE) {
		kmalloc_flags |= __GFP_NOWARN;            // add __GFP_NOWARN for "big" allocations

		if (!(kmalloc_flags & __GFP_RETRY_MAYFAIL))
			kmalloc_flags |= __GFP_NORETRY;
	}

	// kmalloc_flags == GFP_KERNEL|__GFP_ZERO|__GFP_NOWARN if size > PAGE_SIZE
	ret = kmalloc_node(size, kmalloc_flags, node);    

	if (ret || size <= PAGE_SIZE)
		return ret;

	// flags == GFP_KERNEL|__GFP_ZERO
	return __vmalloc_node(size, 1, flags, node,
			__builtin_return_address(0));

So, to my understanding the difference is only that cxgbi_alloc_big_mem adds __GFP_NOWARN
to kzalloc unconditionally, kvzalloc adds __GFP_NOWARN to kmalloc_node if size > PAGE_SIZE.
We use: max_conn * sizeof(struct cxgbi_sock *) in allocation. max_conn can be either
CXGBI_MAX_CONN or CXGB4I_MAX_CONN. CXGBI_MAX_CONN == 16384, CXGB4I_MAX_CONN == 16384.
Thus the allocation is bigger than PAGE_SIZE and kvmalloc_node adds __GFP_NOWARN to the
kmalloc_node call. Maybe I missed something?

Thanks,
Denis

  reply	other threads:[~2020-08-01  7:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31 21:55 [PATCH] scsi: libcxgbi: use kvzalloc instead of opencoded kzalloc/vzalloc Denis Efremov
2020-07-31 21:58 ` Joe Perches
2020-07-31 22:10   ` Denis Efremov
2020-07-31 22:24     ` Joe Perches
2020-08-01  7:51       ` Denis Efremov [this message]
2020-08-01  7:58         ` Denis Efremov
2020-08-01  8:10         ` Joe Perches
2020-08-01 13:28           ` Denis Efremov
2020-08-01 13:31 ` [PATCH v2] " Denis Efremov
2020-08-27 15:13   ` Denis Efremov
2020-08-27 15:17     ` Martin K. Petersen
2020-09-09  2:17   ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c5a18804-3236-9688-2a3c-68184f0dd9e8@linux.com \
    --to=efremov@linux.com \
    --cc=jejb@linux.ibm.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.