On Wed, Jul 11, 2012 at 07:33:41PM -0700, David Rientjes wrote:
> On Thu, 12 Jul 2012, Minchan Kim wrote:
>
> > Agreed and that's why I suggested following patch.
> > It's not elegant but at least, it could attract interest of configuration
> > people and they could find a regression during test
On Thu, 12 Jul 2012, Minchan Kim wrote:
> Agreed and that's why I suggested following patch.
> It's not elegant but at least, it could attract interest of configuration
> people and they could find a regression during test phase.
> This description could be improved later by writing new
On Wed, Jul 11, 2012 at 04:02:00PM -0700, David Rientjes wrote:
> On Thu, 12 Jul 2012, Minchan Kim wrote:
>
> > There is QA team in embedded company and they have tested their product.
> > In test scenario, they can allocate 100 high order allocation.
> > (they don't matter how many high order
On Thu, 12 Jul 2012, Minchan Kim wrote:
> There is QA team in embedded company and they have tested their product.
> In test scenario, they can allocate 100 high order allocation.
> (they don't matter how many high order allocations in kernel are needed
> during test. their concern is just only
On Thu, Jul 12, 2012 at 5:40 AM, David Rientjes wrote:
> On Wed, 11 Jul 2012, Minchan Kim wrote:
>
>> I agree it's an ideal but the problem is that it's too late.
>> Once product is released, we have to recall all products in the worst case.
>> The fact is that lumpy have helped high order
On Wed, 11 Jul 2012, Minchan Kim wrote:
> I agree it's an ideal but the problem is that it's too late.
> Once product is released, we have to recall all products in the worst case.
> The fact is that lumpy have helped high order allocation implicitly but we
> removed it
> without any
On Wed, 11 Jul 2012, Minchan Kim wrote:
I agree it's an ideal but the problem is that it's too late.
Once product is released, we have to recall all products in the worst case.
The fact is that lumpy have helped high order allocation implicitly but we
removed it
without any notification or
On Thu, Jul 12, 2012 at 5:40 AM, David Rientjes rient...@google.com wrote:
On Wed, 11 Jul 2012, Minchan Kim wrote:
I agree it's an ideal but the problem is that it's too late.
Once product is released, we have to recall all products in the worst case.
The fact is that lumpy have helped high
On Thu, 12 Jul 2012, Minchan Kim wrote:
There is QA team in embedded company and they have tested their product.
In test scenario, they can allocate 100 high order allocation.
(they don't matter how many high order allocations in kernel are needed
during test. their concern is just only
On Wed, Jul 11, 2012 at 04:02:00PM -0700, David Rientjes wrote:
On Thu, 12 Jul 2012, Minchan Kim wrote:
There is QA team in embedded company and they have tested their product.
In test scenario, they can allocate 100 high order allocation.
(they don't matter how many high order
On Thu, 12 Jul 2012, Minchan Kim wrote:
Agreed and that's why I suggested following patch.
It's not elegant but at least, it could attract interest of configuration
people and they could find a regression during test phase.
This description could be improved later by writing new documenation
On Wed, Jul 11, 2012 at 07:33:41PM -0700, David Rientjes wrote:
On Thu, 12 Jul 2012, Minchan Kim wrote:
Agreed and that's why I suggested following patch.
It's not elegant but at least, it could attract interest of configuration
people and they could find a regression during test phase.
On 07/11/2012 02:33 PM, David Rientjes wrote:
> On Wed, 11 Jul 2012, Minchan Kim wrote:
>
>>> Should we consider enabling CONFIG_COMPACTION in defconfig? If not, would
>>
>> I hope so but Mel didn't like it because some users want to have a smallest
>> kernel if they don't care of high-order
On Wed, 11 Jul 2012, Minchan Kim wrote:
> > Should we consider enabling CONFIG_COMPACTION in defconfig? If not, would
>
> I hope so but Mel didn't like it because some users want to have a smallest
> kernel if they don't care of high-order allocation.
>
CONFIG_COMPACTION adds 0.1% to my
Hi David,
On Tue, Jul 10, 2012 at 06:02:06PM -0700, David Rientjes wrote:
> On Tue, 10 Jul 2012, Minchan Kim wrote:
>
> > > So I dunno, this all looks like we have a kernel problem and we're
> > > throwing our problem onto hopelessly ill-equipped users of that kernel?
> >
> > As you know, this
On Tue, 10 Jul 2012, Minchan Kim wrote:
> > So I dunno, this all looks like we have a kernel problem and we're
> > throwing our problem onto hopelessly ill-equipped users of that kernel?
>
> As you know, this patch isn't for solving regular high-order allocations.
> As I wrote down, The problem
On Tue, 10 Jul 2012, Minchan Kim wrote:
So I dunno, this all looks like we have a kernel problem and we're
throwing our problem onto hopelessly ill-equipped users of that kernel?
As you know, this patch isn't for solving regular high-order allocations.
As I wrote down, The problem is that
Hi David,
On Tue, Jul 10, 2012 at 06:02:06PM -0700, David Rientjes wrote:
On Tue, 10 Jul 2012, Minchan Kim wrote:
So I dunno, this all looks like we have a kernel problem and we're
throwing our problem onto hopelessly ill-equipped users of that kernel?
As you know, this patch isn't
On Wed, 11 Jul 2012, Minchan Kim wrote:
Should we consider enabling CONFIG_COMPACTION in defconfig? If not, would
I hope so but Mel didn't like it because some users want to have a smallest
kernel if they don't care of high-order allocation.
CONFIG_COMPACTION adds 0.1% to my kernel
On 07/11/2012 02:33 PM, David Rientjes wrote:
On Wed, 11 Jul 2012, Minchan Kim wrote:
Should we consider enabling CONFIG_COMPACTION in defconfig? If not, would
I hope so but Mel didn't like it because some users want to have a smallest
kernel if they don't care of high-order allocation.
Since lumpy reclaim was introduced at 2.6.23, it helped higher
order allocation.
Recently, we removed it at 3.4 and we didn't enable compaction
forcingly[1]. The reason makes sense that compaction.o + migration.o
isn't trivial for system doesn't use higher order allocation.
But the problem is that
Hi Andrew,
On Mon, Jul 09, 2012 at 05:08:56PM -0700, Andrew Morton wrote:
> On Tue, 10 Jul 2012 08:55:53 +0900
> Minchan Kim wrote:
>
> > ...
> >
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -2276,6 +2276,29 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
> > return alloc_flags;
> > }
On Tue, 10 Jul 2012 08:55:53 +0900
Minchan Kim wrote:
> ...
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2276,6 +2276,29 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
> return alloc_flags;
> }
>
> +#if defined(CONFIG_DEBUG_VM) && !defined(CONFIG_COMPACTION)
> +static inline void
Please ignore,
It is sent by mistake. :(
Sorry for the noise.
On Tue, Jul 10, 2012 at 08:55:53AM +0900, Minchan Kim wrote:
> Since lumpy reclaim was introduced at 2.6.23, it helped higher
> order allocation.
> Recently, we removed it at 3.4 and we didn't enable compaction
> forcingly[1]. The
Since lumpy reclaim was introduced at 2.6.23, it helped higher
order allocation.
Recently, we removed it at 3.4 and we didn't enable compaction
forcingly[1]. The reason makes sense that compaction.o + migration.o
isn't trivial for system doesn't use higher order allocation.
But the problem is that
Since lumpy reclaim was introduced at 2.6.23, it helped higher
order allocation.
Recently, we removed it at 3.4 and we didn't enable compaction
forcingly[1]. The reason makes sense that compaction.o + migration.o
isn't trivial for system doesn't use higher order allocation.
But the problem is that
Please ignore,
It is sent by mistake. :(
Sorry for the noise.
On Tue, Jul 10, 2012 at 08:55:53AM +0900, Minchan Kim wrote:
Since lumpy reclaim was introduced at 2.6.23, it helped higher
order allocation.
Recently, we removed it at 3.4 and we didn't enable compaction
forcingly[1]. The reason
On Tue, 10 Jul 2012 08:55:53 +0900
Minchan Kim minc...@kernel.org wrote:
...
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2276,6 +2276,29 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
return alloc_flags;
}
+#if defined(CONFIG_DEBUG_VM) !defined(CONFIG_COMPACTION)
+static inline
Hi Andrew,
On Mon, Jul 09, 2012 at 05:08:56PM -0700, Andrew Morton wrote:
On Tue, 10 Jul 2012 08:55:53 +0900
Minchan Kim minc...@kernel.org wrote:
...
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2276,6 +2276,29 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
return alloc_flags;
}
Since lumpy reclaim was introduced at 2.6.23, it helped higher
order allocation.
Recently, we removed it at 3.4 and we didn't enable compaction
forcingly[1]. The reason makes sense that compaction.o + migration.o
isn't trivial for system doesn't use higher order allocation.
But the problem is that
30 matches
Mail list logo
