On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should start swapping before we hit
the point where non movable kernel allocation fails, no?
Possibly but the fact remains, this can be avoided by making
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should start swapping before we hit
the point where non movable kernel allocation fails, no?
On 06.05.14 09:19, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should start swapping before we hit
the point
Alexander Graf ag...@suse.de writes:
On 06.05.14 09:19, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should
On 05/06/2014 04:20 PM, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 06.05.14 09:19, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should start swapping before we hit
the point where non movable kernel allocation fails, no?
Possibly but the fact remains, this can be avoided by making
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should start swapping before we hit
the point where non movable kernel allocation fails, no?
On 06.05.14 09:19, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should start swapping before we hit
the point
Alexander Graf ag...@suse.de writes:
On 06.05.14 09:19, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should
On 05/06/2014 04:20 PM, Aneesh Kumar K.V wrote:
Alexander Graf ag...@suse.de writes:
On 06.05.14 09:19, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf
On 05/04/2014 07:25 PM, Aneesh Kumar K.V wrote:
We reserve 5% of total ram for CMA allocation and not using that can
result in us running out of numa node memory with specific
configuration. One caveat is we may not have node local hpt with pinned
vcpu configuration. But currently libvirt also
Alexander Graf ag...@suse.de writes:
On 05/04/2014 07:25 PM, Aneesh Kumar K.V wrote:
We reserve 5% of total ram for CMA allocation and not using that can
result in us running out of numa node memory with specific
configuration. One caveat is we may not have node local hpt with pinned
vcpu
Am 05.05.2014 um 16:35 schrieb Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com:
Alexander Graf ag...@suse.de writes:
On 05/04/2014 07:25 PM, Aneesh Kumar K.V wrote:
We reserve 5% of total ram for CMA allocation and not using that can
result in us running out of numa node memory with
Alexander Graf ag...@suse.de writes:
Am 05.05.2014 um 16:35 schrieb Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com:
Alexander Graf ag...@suse.de writes:
On 05/04/2014 07:25 PM, Aneesh Kumar K.V wrote:
We reserve 5% of total ram for CMA allocation and not using that can
result in us
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should start swapping before we hit
the point where non movable kernel allocation fails, no?
Possibly but the fact remains, this can be avoided by making sure that
if we create a CMA reserve for KVM, then
We reserve 5% of total ram for CMA allocation and not using that can
result in us running out of numa node memory with specific
configuration. One caveat is we may not have node local hpt with pinned
vcpu configuration. But currently libvirt also pins the vcpu to cpuset
after creating hash page
16 matches
Mail list logo