linux-kernel - RE: [PATCH V2 3/3] Drivers: hv: vmbus: Allocate ring buffer memory in NUMA aware fashion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <BY2PR0301MB16548082EDF92C561DC31122A0B70@BY2PR0301MB1654.namprd03.prod.outlook.com>
Date:	Sun, 31 May 2015 18:39:59 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"olaf@...fle.de" <olaf@...fle.de>,
	"apw@...onical.com" <apw@...onical.com>,
	"vkuznets@...hat.com" <vkuznets@...hat.com>,
	"jasowang@...hat.com" <jasowang@...hat.com>
Subject: RE: [PATCH V2 3/3] Drivers: hv: vmbus: Allocate ring buffer memory in
 NUMA aware fashion



> -----Original Message-----
> From: Greg KH [mailto:gregkh@...uxfoundation.org]
> Sent: Saturday, May 30, 2015 11:41 PM
> To: KY Srinivasan
> Cc: linux-kernel@...r.kernel.org; devel@...uxdriverproject.org;
> olaf@...fle.de; apw@...onical.com; vkuznets@...hat.com;
> jasowang@...hat.com
> Subject: Re: [PATCH V2 3/3] Drivers: hv: vmbus: Allocate ring buffer memory
> in NUMA aware fashion
> 
> On Sat, May 30, 2015 at 11:37:49PM -0700, K. Y. Srinivasan wrote:
> > Allocate ring buffer memory from the NUMA node assigned to the
> channel.
> 
> But you do more than just that.  If there's a failure, you fall-back to
> the old allocation method.  Why not mention that as well?

I will mention this in the change log. 
> 
> And is that what you really want?  Do we ever fail allocation for a node
> but still have memory from another one?  Shouldn't the logic be in the
> allocator and not be forced to be in every caller?

I do want this behavior. The allocation from a specific node is just to maintain NUMA
locality and there is no correctness issue even if the allocation came from a non-preferred
node. So, I don't want to fail the load of the driver just because I could not allocate from
the preferred node.
To answer your second question,  I think the allocation can fail when we specify a specific node,
when there may be memory available on other zones and the specified node has no free memory.
I think it is good to have the caller deal with this case since in some cases we would rather fail if we cannot
allocate memory from the specified node.

Regards,

K. Y
> 
> thanks,
> 
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/