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 p
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 documenati
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 all
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 wo
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 allocat
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
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 all
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 kerne
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 p
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 i
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 check
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 reaso
13 matches
Mail list logo
