On Mon, 6 Jan 2014, Wanpeng Li wrote:
> >Is there any progress against slub's fix?
> >
> >MemTotal:7760960 kB
> >Slab:7064448 kB
> >SReclaimable: 143936 kB
> >SUnreclaim: 6920512 kB
> >
> >112084 10550 9% 16.00K 3507 32 1795584K kmalloc-16384
> >2497920
On Mon, 6 Jan 2014, Wanpeng Li wrote:
Is there any progress against slub's fix?
MemTotal:7760960 kB
Slab:7064448 kB
SReclaimable: 143936 kB
SUnreclaim: 6920512 kB
112084 10550 9% 16.00K 3507 32 1795584K kmalloc-16384
2497920 48092 1%
On Fri, 3 May 2013, Michal Hocko wrote:
> > Both should be fixed.
>
> Could you point to the specific commit(s), please?
>
> > Making requests for large amounts of memory from an allocator that is
> > supposed to hand out fraction of a page does not make sense.
>
> AFAIR there were lots of
On Fri 03-05-13 15:25:25, Christoph Lameter wrote:
> On Fri, 3 May 2013, Han Pingtian wrote:
>
> > On Thu, May 02, 2013 at 03:10:15PM +, Christoph Lameter wrote:
> > > On Thu, 2 May 2013, Han Pingtian wrote:
> > >
> > > > Looks like "ibmvscsi" + "slub" can trigger this problem.
> > >
> > >
On Fri, 3 May 2013, Han Pingtian wrote:
> On Thu, May 02, 2013 at 03:10:15PM +, Christoph Lameter wrote:
> > On Thu, 2 May 2013, Han Pingtian wrote:
> >
> > > Looks like "ibmvscsi" + "slub" can trigger this problem.
> >
> > And the next merge of the slab-next tree will also cause SLAB to
On Fri, 3 May 2013, Han Pingtian wrote:
On Thu, May 02, 2013 at 03:10:15PM +, Christoph Lameter wrote:
On Thu, 2 May 2013, Han Pingtian wrote:
Looks like ibmvscsi + slub can trigger this problem.
And the next merge of the slab-next tree will also cause SLAB to trigger
this
On Fri 03-05-13 15:25:25, Christoph Lameter wrote:
On Fri, 3 May 2013, Han Pingtian wrote:
On Thu, May 02, 2013 at 03:10:15PM +, Christoph Lameter wrote:
On Thu, 2 May 2013, Han Pingtian wrote:
Looks like ibmvscsi + slub can trigger this problem.
And the next merge of the
On Fri, 3 May 2013, Michal Hocko wrote:
Both should be fixed.
Could you point to the specific commit(s), please?
Making requests for large amounts of memory from an allocator that is
supposed to hand out fraction of a page does not make sense.
AFAIR there were lots of objects in
On Thu, May 02, 2013 at 03:10:15PM +, Christoph Lameter wrote:
> On Thu, 2 May 2013, Han Pingtian wrote:
>
> > Looks like "ibmvscsi" + "slub" can trigger this problem.
>
> And the next merge of the slab-next tree will also cause SLAB to trigger
> this issue. I would like to have this fixes.
On Wed, 1 May 2013, Will Huck wrote:
> > Age refers to the mininum / avg / maximum age of the object in ticks.
>
> Why need monitor the age of the object?
Will give you some idea as to when these objects were created.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, 2 May 2013, Han Pingtian wrote:
> Looks like "ibmvscsi" + "slub" can trigger this problem.
And the next merge of the slab-next tree will also cause SLAB to trigger
this issue. I would like to have this fixes. The slab allocator purpose is
to servr objects that are a fraction of a page
On Mon, Apr 29, 2013 at 04:57:11PM +0200, Michal Hocko wrote:
> On Mon 29-04-13 14:50:08, Christoph Lameter wrote:
> > On Sat, 27 Apr 2013, Han Pingtian wrote:
> >
> > > and it is called so many times that the boot cannot be finished. So
> > > maybe the memory isn't freed even though
On Mon, Apr 29, 2013 at 04:57:11PM +0200, Michal Hocko wrote:
On Mon 29-04-13 14:50:08, Christoph Lameter wrote:
On Sat, 27 Apr 2013, Han Pingtian wrote:
and it is called so many times that the boot cannot be finished. So
maybe the memory isn't freed even though __free_slab() get
On Thu, 2 May 2013, Han Pingtian wrote:
Looks like ibmvscsi + slub can trigger this problem.
And the next merge of the slab-next tree will also cause SLAB to trigger
this issue. I would like to have this fixes. The slab allocator purpose is
to servr objects that are a fraction of a page and not
On Wed, 1 May 2013, Will Huck wrote:
Age refers to the mininum / avg / maximum age of the object in ticks.
Why need monitor the age of the object?
Will give you some idea as to when these objects were created.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Thu, May 02, 2013 at 03:10:15PM +, Christoph Lameter wrote:
On Thu, 2 May 2013, Han Pingtian wrote:
Looks like ibmvscsi + slub can trigger this problem.
And the next merge of the slab-next tree will also cause SLAB to trigger
this issue. I would like to have this fixes. The slab
Hi Christoph,
On 04/29/2013 10:49 PM, Christoph Lameter wrote:
On Sat, 27 Apr 2013, Will Huck wrote:
Hi Christoph,
On 04/26/2013 01:17 AM, Christoph Lameter wrote:
On Thu, 25 Apr 2013, Han Pingtian wrote:
I have enabled "slub_debug" and here is the
/sys/kernel/slab/kmalloc-512/alloc_calls
Hi Christoph,
On 04/29/2013 10:49 PM, Christoph Lameter wrote:
On Sat, 27 Apr 2013, Will Huck wrote:
Hi Christoph,
On 04/26/2013 01:17 AM, Christoph Lameter wrote:
On Thu, 25 Apr 2013, Han Pingtian wrote:
I have enabled slub_debug and here is the
/sys/kernel/slab/kmalloc-512/alloc_calls
On Mon 29-04-13 14:50:08, Christoph Lameter wrote:
> On Sat, 27 Apr 2013, Han Pingtian wrote:
>
> > and it is called so many times that the boot cannot be finished. So
> > maybe the memory isn't freed even though __free_slab() get called?
>
> Ok that suggests an issue with the page allocator
On Sat, 27 Apr 2013, Han Pingtian wrote:
> and it is called so many times that the boot cannot be finished. So
> maybe the memory isn't freed even though __free_slab() get called?
Ok that suggests an issue with the page allocator then.
--
To unsubscribe from this list: send the line "unsubscribe
On Sat, 27 Apr 2013, Will Huck wrote:
> Hi Christoph,
> On 04/26/2013 01:17 AM, Christoph Lameter wrote:
> > On Thu, 25 Apr 2013, Han Pingtian wrote:
> >
> > > I have enabled "slub_debug" and here is the
> > > /sys/kernel/slab/kmalloc-512/alloc_calls contents:
> > >
> > > 50
On Sat, 27 Apr 2013, Will Huck wrote:
Hi Christoph,
On 04/26/2013 01:17 AM, Christoph Lameter wrote:
On Thu, 25 Apr 2013, Han Pingtian wrote:
I have enabled slub_debug and here is the
/sys/kernel/slab/kmalloc-512/alloc_calls contents:
50 .__alloc_workqueue_key+0x90/0x5d0
On Sat, 27 Apr 2013, Han Pingtian wrote:
and it is called so many times that the boot cannot be finished. So
maybe the memory isn't freed even though __free_slab() get called?
Ok that suggests an issue with the page allocator then.
--
To unsubscribe from this list: send the line unsubscribe
On Mon 29-04-13 14:50:08, Christoph Lameter wrote:
On Sat, 27 Apr 2013, Han Pingtian wrote:
and it is called so many times that the boot cannot be finished. So
maybe the memory isn't freed even though __free_slab() get called?
Ok that suggests an issue with the page allocator then.
You
On Fri, Apr 26, 2013 at 02:42:32PM +, Christoph Lameter wrote:
> On Fri, 26 Apr 2013, Han Pingtian wrote:
>
> > Could you give me some hints about how to verify them? Only I can do is
> > adding two printk() statements to print the vaules in those two
> > functions:
>
> Ok thats good.
Hi Christoph,
On 04/26/2013 01:17 AM, Christoph Lameter wrote:
On Thu, 25 Apr 2013, Han Pingtian wrote:
I have enabled "slub_debug" and here is the
/sys/kernel/slab/kmalloc-512/alloc_calls contents:
50 .__alloc_workqueue_key+0x90/0x5d0 age=113630/116957/119419 pid=1-1730
Hi Christoph,
On 04/26/2013 01:17 AM, Christoph Lameter wrote:
On Thu, 25 Apr 2013, Han Pingtian wrote:
I have enabled slub_debug and here is the
/sys/kernel/slab/kmalloc-512/alloc_calls contents:
50 .__alloc_workqueue_key+0x90/0x5d0 age=113630/116957/119419 pid=1-1730
On Fri, Apr 26, 2013 at 02:42:32PM +, Christoph Lameter wrote:
On Fri, 26 Apr 2013, Han Pingtian wrote:
Could you give me some hints about how to verify them? Only I can do is
adding two printk() statements to print the vaules in those two
functions:
Ok thats good. nr-partial needs
On Fri, 26 Apr 2013, Han Pingtian wrote:
> Could you give me some hints about how to verify them? Only I can do is
> adding two printk() statements to print the vaules in those two
> functions:
Ok thats good. nr->partial needs to be bigger than min_partial in order
for frees to occur. So they do
On Thu, Apr 25, 2013 at 06:24:05PM +, Christoph Lameter wrote:
> On Thu, 25 Apr 2013, Han Pingtian wrote:
>
> > > A dump of the other fields in /sys/kernel/slab/kmalloc*/* would also be
> > > useful.
> > >
> > I have dumpped all /sys/kernel/slab/kmalloc*/* in kmalloc.tar.xz and
> > will
On Thu, Apr 25, 2013 at 06:24:05PM +, Christoph Lameter wrote:
On Thu, 25 Apr 2013, Han Pingtian wrote:
A dump of the other fields in /sys/kernel/slab/kmalloc*/* would also be
useful.
I have dumpped all /sys/kernel/slab/kmalloc*/* in kmalloc.tar.xz and
will attach it to this
On Fri, 26 Apr 2013, Han Pingtian wrote:
Could you give me some hints about how to verify them? Only I can do is
adding two printk() statements to print the vaules in those two
functions:
Ok thats good. nr-partial needs to be bigger than min_partial in order
for frees to occur. So they do
On Thu, 25 Apr 2013, Han Pingtian wrote:
> > A dump of the other fields in /sys/kernel/slab/kmalloc*/* would also be
> > useful.
> >
> I have dumpped all /sys/kernel/slab/kmalloc*/* in kmalloc.tar.xz and
> will attach it to this mail.
Ok that looks like a lot of objects were freed from slab
On Thu, 25 Apr 2013, Han Pingtian wrote:
> I have enabled "slub_debug" and here is the
> /sys/kernel/slab/kmalloc-512/alloc_calls contents:
>
> 50 .__alloc_workqueue_key+0x90/0x5d0 age=113630/116957/119419 pid=1-1730
> cpus=0,6-8,13,24,26,44,53,57,60,68 nodes=1
> 11
On Wed, Apr 24, 2013 at 03:36:20PM +, Christoph Lameter wrote:
> On Wed, 24 Apr 2013, Michal Hocko wrote:
>
> > [CCing SL.B people and linux-mm list]
> >
> > Just for quick summary. The reporter sees OOM situations with almost
> > whole memory filled with slab memory. This is a powerpc
On Wed, Apr 24, 2013 at 03:36:20PM +, Christoph Lameter wrote:
On Wed, 24 Apr 2013, Michal Hocko wrote:
[CCing SL.B people and linux-mm list]
Just for quick summary. The reporter sees OOM situations with almost
whole memory filled with slab memory. This is a powerpc machine with 4G
On Thu, 25 Apr 2013, Han Pingtian wrote:
I have enabled slub_debug and here is the
/sys/kernel/slab/kmalloc-512/alloc_calls contents:
50 .__alloc_workqueue_key+0x90/0x5d0 age=113630/116957/119419 pid=1-1730
cpus=0,6-8,13,24,26,44,53,57,60,68 nodes=1
11
On Thu, 25 Apr 2013, Han Pingtian wrote:
A dump of the other fields in /sys/kernel/slab/kmalloc*/* would also be
useful.
I have dumpped all /sys/kernel/slab/kmalloc*/* in kmalloc.tar.xz and
will attach it to this mail.
Ok that looks like a lot of objects were freed from slab pages but
On Wed, 24 Apr 2013, Michal Hocko wrote:
> [CCing SL.B people and linux-mm list]
>
> Just for quick summary. The reporter sees OOM situations with almost
> whole memory filled with slab memory. This is a powerpc machine with 4G
> RAM.
Boot with "slub_debug" or enable slab debugging.
>
[CCing SL.B people and linux-mm list]
Just for quick summary. The reporter sees OOM situations with almost
whole memory filled with slab memory. This is a powerpc machine with 4G
RAM.
/proc/slabinfo shows that almost whole slab occupied memory is on
free lists which for some reason don't get
[CCing SL.B people and linux-mm list]
Just for quick summary. The reporter sees OOM situations with almost
whole memory filled with slab memory. This is a powerpc machine with 4G
RAM.
/proc/slabinfo shows that almost whole slab occupied memory is on
free lists which for some reason don't get
On Wed, 24 Apr 2013, Michal Hocko wrote:
[CCing SL.B people and linux-mm list]
Just for quick summary. The reporter sees OOM situations with almost
whole memory filled with slab memory. This is a powerpc machine with 4G
RAM.
Boot with slub_debug or enable slab debugging.
/proc/slabinfo
On Tue, Apr 23, 2013 at 03:15:58PM +0200, Michal Hocko wrote:
> On Tue 23-04-13 12:22:34, Han Pingtian wrote:
> > On Mon, Apr 22, 2013 at 01:40:52PM +0200, Michal Hocko wrote:
> > > > CONFIG_PPC_BOOK3S_64=y
> > > > # CONFIG_PPC_BOOK3E_64 is not set
> > > > -CONFIG_GENERIC_CPU=y
> > > > +#
On Tue 23-04-13 12:22:34, Han Pingtian wrote:
> On Mon, Apr 22, 2013 at 01:40:52PM +0200, Michal Hocko wrote:
> > > CONFIG_PPC_BOOK3S_64=y
> > > # CONFIG_PPC_BOOK3E_64 is not set
> > > -CONFIG_GENERIC_CPU=y
> > > +# CONFIG_GENERIC_CPU is not set
> > > # CONFIG_CELL_CPU is not set
> > > #
On Tue 23-04-13 12:22:34, Han Pingtian wrote:
On Mon, Apr 22, 2013 at 01:40:52PM +0200, Michal Hocko wrote:
CONFIG_PPC_BOOK3S_64=y
# CONFIG_PPC_BOOK3E_64 is not set
-CONFIG_GENERIC_CPU=y
+# CONFIG_GENERIC_CPU is not set
# CONFIG_CELL_CPU is not set
# CONFIG_POWER4_CPU is not
On Tue, Apr 23, 2013 at 03:15:58PM +0200, Michal Hocko wrote:
On Tue 23-04-13 12:22:34, Han Pingtian wrote:
On Mon, Apr 22, 2013 at 01:40:52PM +0200, Michal Hocko wrote:
CONFIG_PPC_BOOK3S_64=y
# CONFIG_PPC_BOOK3E_64 is not set
-CONFIG_GENERIC_CPU=y
+# CONFIG_GENERIC_CPU is not
On Mon, Apr 22, 2013 at 01:40:52PM +0200, Michal Hocko wrote:
> > CONFIG_PPC_BOOK3S_64=y
> > # CONFIG_PPC_BOOK3E_64 is not set
> > -CONFIG_GENERIC_CPU=y
> > +# CONFIG_GENERIC_CPU is not set
> > # CONFIG_CELL_CPU is not set
> > # CONFIG_POWER4_CPU is not set
> > # CONFIG_POWER5_CPU is not set
On Mon 22-04-13 11:18:49, Han Pingtian wrote:
> On Fri, Apr 19, 2013 at 09:43:10AM -0700, Michal Hocko wrote:
> > [Do not drop people from the CC please]
> >
> > On Fri 19-04-13 10:33:45, Han Pingtian wrote:
> > > On Thu, Apr 18, 2013 at 10:55:14AM -0700, Michal Hocko wrote:
> > [...]
> > > >
On Mon 22-04-13 11:18:49, Han Pingtian wrote:
On Fri, Apr 19, 2013 at 09:43:10AM -0700, Michal Hocko wrote:
[Do not drop people from the CC please]
On Fri 19-04-13 10:33:45, Han Pingtian wrote:
On Thu, Apr 18, 2013 at 10:55:14AM -0700, Michal Hocko wrote:
[...]
What is the kernel
On Mon, Apr 22, 2013 at 01:40:52PM +0200, Michal Hocko wrote:
CONFIG_PPC_BOOK3S_64=y
# CONFIG_PPC_BOOK3E_64 is not set
-CONFIG_GENERIC_CPU=y
+# CONFIG_GENERIC_CPU is not set
# CONFIG_CELL_CPU is not set
# CONFIG_POWER4_CPU is not set
# CONFIG_POWER5_CPU is not set
#
On Sun, Apr 21, 2013 at 02:49:31AM +0200, Jiri Kosina wrote:
> On Wed, 17 Apr 2013, Han Pingtian wrote:
>
> > > > On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
> > > > something like "make -j 64" to compile linux kernel from source, sooner
> > > > or latter, oom-killer
On Sun, Apr 21, 2013 at 02:49:31AM +0200, Jiri Kosina wrote:
On Wed, 17 Apr 2013, Han Pingtian wrote:
On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
something like make -j 64 to compile linux kernel from source, sooner
or latter, oom-killer will be
On Wed, 17 Apr 2013, Han Pingtian wrote:
> > > On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
> > > something like "make -j 64" to compile linux kernel from source, sooner
> > > or latter, oom-killer will be triggered. Before that, when I trying to
> > > analyse the live
On Wed, 17 Apr 2013, Han Pingtian wrote:
On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
something like make -j 64 to compile linux kernel from source, sooner
or latter, oom-killer will be triggered. Before that, when I trying to
analyse the live system with
[Do not drop people from the CC please]
On Fri 19-04-13 10:33:45, Han Pingtian wrote:
> On Thu, Apr 18, 2013 at 10:55:14AM -0700, Michal Hocko wrote:
[...]
> > What is the kernel that you are using and what config?
> >
> We are testing a alpha version of a enterprise linux which using a 3.7
>
[Do not drop people from the CC please]
On Fri 19-04-13 10:33:45, Han Pingtian wrote:
On Thu, Apr 18, 2013 at 10:55:14AM -0700, Michal Hocko wrote:
[...]
What is the kernel that you are using and what config?
We are testing a alpha version of a enterprise linux which using a 3.7
series
On Thu, Apr 18, 2013 at 10:55:14AM -0700, Michal Hocko wrote:
> On Fri 19-04-13 00:55:31, Han Pingtian wrote:
> > On Thu, Apr 18, 2013 at 07:17:36AM -0700, Michal Hocko wrote:
> > > On Thu 18-04-13 18:15:41, Han Pingtian wrote:
> > > > On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
On Fri 19-04-13 00:55:31, Han Pingtian wrote:
> On Thu, Apr 18, 2013 at 07:17:36AM -0700, Michal Hocko wrote:
> > On Thu 18-04-13 18:15:41, Han Pingtian wrote:
> > > On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
> > > > On Wed 17-04-13 17:47:50, Han Pingtian wrote:
> > > > > [
On Thu, Apr 18, 2013 at 07:17:36AM -0700, Michal Hocko wrote:
> On Thu 18-04-13 18:15:41, Han Pingtian wrote:
> > On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
> > > On Wed 17-04-13 17:47:50, Han Pingtian wrote:
> > > > [ 5233.949714] Node 1 DMA free:3968kB min:7808kB low:9728kB
>
On Thu 18-04-13 18:15:41, Han Pingtian wrote:
> On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
> > On Wed 17-04-13 17:47:50, Han Pingtian wrote:
> > > [ 5233.949714] Node 1 DMA free:3968kB min:7808kB low:9728kB high:11712kB
> > > active_anon:0kB inactive_anon:3584kB
On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
> On Wed 17-04-13 17:47:50, Han Pingtian wrote:
> > [ 5233.949714] Node 1 DMA free:3968kB min:7808kB low:9728kB high:11712kB
> > active_anon:0kB inactive_anon:3584kB active_file:2240kB inactive_file:576kB
> > unevictable:0kB
On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
On Wed 17-04-13 17:47:50, Han Pingtian wrote:
[ 5233.949714] Node 1 DMA free:3968kB min:7808kB low:9728kB high:11712kB
active_anon:0kB inactive_anon:3584kB active_file:2240kB inactive_file:576kB
unevictable:0kB
On Thu 18-04-13 18:15:41, Han Pingtian wrote:
On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
On Wed 17-04-13 17:47:50, Han Pingtian wrote:
[ 5233.949714] Node 1 DMA free:3968kB min:7808kB low:9728kB high:11712kB
active_anon:0kB inactive_anon:3584kB active_file:2240kB
On Thu, Apr 18, 2013 at 07:17:36AM -0700, Michal Hocko wrote:
On Thu 18-04-13 18:15:41, Han Pingtian wrote:
On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
On Wed 17-04-13 17:47:50, Han Pingtian wrote:
[ 5233.949714] Node 1 DMA free:3968kB min:7808kB low:9728kB
On Fri 19-04-13 00:55:31, Han Pingtian wrote:
On Thu, Apr 18, 2013 at 07:17:36AM -0700, Michal Hocko wrote:
On Thu 18-04-13 18:15:41, Han Pingtian wrote:
On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
On Wed 17-04-13 17:47:50, Han Pingtian wrote:
[ 5233.949714] Node 1
On Thu, Apr 18, 2013 at 10:55:14AM -0700, Michal Hocko wrote:
On Fri 19-04-13 00:55:31, Han Pingtian wrote:
On Thu, Apr 18, 2013 at 07:17:36AM -0700, Michal Hocko wrote:
On Thu 18-04-13 18:15:41, Han Pingtian wrote:
On Wed, Apr 17, 2013 at 07:19:09AM -0700, Michal Hocko wrote:
On
On Wed 17-04-13 17:47:50, Han Pingtian wrote:
> [ 5233.949714] Node 1 DMA free:3968kB min:7808kB low:9728kB high:11712kB
> active_anon:0kB inactive_anon:3584kB active_file:2240kB inactive_file:576kB
> unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4194304kB
> managed:3854464kB
On Tue, Apr 16, 2013 at 01:16:42PM -0700, David Rientjes wrote:
> On Tue, 16 Apr 2013, Han Pingtian wrote:
>
> > Hi list,
> >
> > On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
> > something like "make -j 64" to compile linux kernel from source, sooner
> > or latter,
On Tue, Apr 16, 2013 at 01:16:42PM -0700, David Rientjes wrote:
> On Tue, 16 Apr 2013, Han Pingtian wrote:
>
> > Hi list,
> >
> > On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
> > something like "make -j 64" to compile linux kernel from source, sooner
> > or latter,
On Tue, Apr 16, 2013 at 01:16:42PM -0700, David Rientjes wrote:
On Tue, 16 Apr 2013, Han Pingtian wrote:
Hi list,
On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
something like make -j 64 to compile linux kernel from source, sooner
or latter, oom-killer will
On Tue, Apr 16, 2013 at 01:16:42PM -0700, David Rientjes wrote:
On Tue, 16 Apr 2013, Han Pingtian wrote:
Hi list,
On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
something like make -j 64 to compile linux kernel from source, sooner
or latter, oom-killer will
On Wed 17-04-13 17:47:50, Han Pingtian wrote:
[ 5233.949714] Node 1 DMA free:3968kB min:7808kB low:9728kB high:11712kB
active_anon:0kB inactive_anon:3584kB active_file:2240kB inactive_file:576kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:4194304kB
managed:3854464kB
On Tue, 16 Apr 2013, Han Pingtian wrote:
> Hi list,
>
> On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
> something like "make -j 64" to compile linux kernel from source, sooner
> or latter, oom-killer will be triggered. Before that, when I trying to
> analyse the live
Hi list,
On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
something like "make -j 64" to compile linux kernel from source, sooner
or latter, oom-killer will be triggered. Before that, when I trying to
analyse the live system with crash, some processes' %MEM and RSS looks
Hi list,
On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
something like make -j 64 to compile linux kernel from source, sooner
or latter, oom-killer will be triggered. Before that, when I trying to
analyse the live system with crash, some processes' %MEM and RSS looks
too
On Tue, 16 Apr 2013, Han Pingtian wrote:
Hi list,
On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
something like make -j 64 to compile linux kernel from source, sooner
or latter, oom-killer will be triggered. Before that, when I trying to
analyse the live system
76 matches
Mail list logo
