On Tue, Oct 04, 2016 at 11:48:30AM +1100, Balbir Singh wrote:
On 27/09/16 10:14, Reza Arbab wrote:
Right. To be clear, the background info I put in the commit log
refers to x86, where the SRAT can describe movable nodes which exist
at boot. They're trying to avoid allocations from those nodes
On Tue, Oct 04, 2016 at 11:48:30AM +1100, Balbir Singh wrote:
On 27/09/16 10:14, Reza Arbab wrote:
Right. To be clear, the background info I put in the commit log
refers to x86, where the SRAT can describe movable nodes which exist
at boot. They're trying to avoid allocations from those nodes
On 27/09/16 10:14, Reza Arbab wrote:
> On Tue, Sep 27, 2016 at 07:12:31AM +1000, Benjamin Herrenschmidt wrote:
>> In any case, if the memory hasn't been hotplug, this shouldn't be necessary
>> as we shouldn't be considering it for allocation.
>
> Right. To be clear, the background info I put
On 27/09/16 10:14, Reza Arbab wrote:
> On Tue, Sep 27, 2016 at 07:12:31AM +1000, Benjamin Herrenschmidt wrote:
>> In any case, if the memory hasn't been hotplug, this shouldn't be necessary
>> as we shouldn't be considering it for allocation.
>
> Right. To be clear, the background info I put
On Tue, Sep 27, 2016 at 07:12:31AM +1000, Benjamin Herrenschmidt wrote:
In any case, if the memory hasn't been hotplug, this shouldn't be
necessary as we shouldn't be considering it for allocation.
Right. To be clear, the background info I put in the commit log refers
to x86, where the SRAT
On Tue, Sep 27, 2016 at 07:12:31AM +1000, Benjamin Herrenschmidt wrote:
In any case, if the memory hasn't been hotplug, this shouldn't be
necessary as we shouldn't be considering it for allocation.
Right. To be clear, the background info I put in the commit log refers
to x86, where the SRAT
On Sun, 2016-09-25 at 13:36 -0500, Reza Arbab wrote:
> At boot, the movable_node option sets bottom-up memblock allocation.
>
> This reduces the chance that, in the window before movable memory has
> been identified, an allocation for the kernel might come from a movable
> node. By going
On Sun, 2016-09-25 at 13:36 -0500, Reza Arbab wrote:
> At boot, the movable_node option sets bottom-up memblock allocation.
>
> This reduces the chance that, in the window before movable memory has
> been identified, an allocation for the kernel might come from a movable
> node. By going
On Mon, Sep 26, 2016 at 09:17:43PM +0530, Aneesh Kumar K.V wrote:
+ /* bottom-up allocation may have been set by movable_node */
+ memblock_set_bottom_up(false);
+
By then we have done few memblock allocation right ?
Yes, some allocations do occur while bottom-up is set.
IMHO,
On Mon, Sep 26, 2016 at 09:17:43PM +0530, Aneesh Kumar K.V wrote:
+ /* bottom-up allocation may have been set by movable_node */
+ memblock_set_bottom_up(false);
+
By then we have done few memblock allocation right ?
Yes, some allocations do occur while bottom-up is set.
IMHO,
Reza Arbab writes:
> At boot, the movable_node option sets bottom-up memblock allocation.
>
> This reduces the chance that, in the window before movable memory has
> been identified, an allocation for the kernel might come from a movable
> node. By going bottom-up,
Reza Arbab writes:
> At boot, the movable_node option sets bottom-up memblock allocation.
>
> This reduces the chance that, in the window before movable memory has
> been identified, an allocation for the kernel might come from a movable
> node. By going bottom-up, early allocations will most
At boot, the movable_node option sets bottom-up memblock allocation.
This reduces the chance that, in the window before movable memory has
been identified, an allocation for the kernel might come from a movable
node. By going bottom-up, early allocations will most likely come from
the same node
At boot, the movable_node option sets bottom-up memblock allocation.
This reduces the chance that, in the window before movable memory has
been identified, an allocation for the kernel might come from a movable
node. By going bottom-up, early allocations will most likely come from
the same node
14 matches
Mail list logo