On Mon, Jul 9, 2012 at 10:12 PM, Minchan Kim wrote:
>
> Embedded can use CONFIG_PRINTK and !CONFIG_BUG for size optimization
> and printk(pr_xxx) + dump_stack is common technic used in all over kernel
> sources. Do you have any reason you don't like it?
>
No, I am just feeling like it is a kind o
On Mon, 9 Jul 2012 22:19:42 +0900
Minchan Kim wrote:
> > As you are using printk_ratelimit()
include/linux/printk.h sayeth
/*
* Please don't use printk_ratelimit(), because it shares ratelimiting state
* with all other unrelated printk_ratelimit() callsites. Instead use
* printk_ratelimited
Hi Cong,
On Mon, Jul 09, 2012 at 12:53:22PM +, Cong Wang wrote:
> On Mon, 09 Jul 2012 at 08:46 GMT, Minchan Kim wrote:
> >>
> >> WARN_ON_ONCE would tell you what is trying to satisfy the allocation.
> >
> > Do you mean that it would be better to use WARN_ON_ONCE rather than raw
> > printk?
On Mon, Jul 09, 2012 at 02:05:51PM +0100, Mel Gorman wrote:
> On Mon, Jul 09, 2012 at 09:50:48PM +0900, Minchan Kim wrote:
> > >
> > >
> > > You're aiming this at embedded QA people according to your changelog so
> > > do whatever you think is going to be the most effective. It's already
> > > "k
On Mon, Jul 09, 2012 at 09:50:48PM +0900, Minchan Kim wrote:
> >
> >
> > You're aiming this at embedded QA people according to your changelog so
> > do whatever you think is going to be the most effective. It's already
> > "known" that high-order kernel allocations are meant to be unreliable and
On Mon, 09 Jul 2012 at 08:46 GMT, Minchan Kim wrote:
>>
>> WARN_ON_ONCE would tell you what is trying to satisfy the allocation.
>
> Do you mean that it would be better to use WARN_ON_ONCE rather than raw
> printk?
> If so, I would like to insist raw printk because WARN_ON_ONCE could be
> disab
On Mon, Jul 09, 2012 at 10:12:03AM +0100, Mel Gorman wrote:
> On Mon, Jul 09, 2012 at 05:46:57PM +0900, Minchan Kim wrote:
> > > >
> > > > +#if defined(CONFIG_DEBUG_VM) && !defined(CONFIG_COMPACTION)
> > > > +static inline void check_page_alloc_costly_order(unsigned int order)
> > > > +{
> > > > +
On Mon, Jul 09, 2012 at 05:46:57PM +0900, Minchan Kim wrote:
> > >
> > > +#if defined(CONFIG_DEBUG_VM) && !defined(CONFIG_COMPACTION)
> > > +static inline void check_page_alloc_costly_order(unsigned int order)
> > > +{
> > > + if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER)) {
> > > + printk
Hi Mel,
On Mon, Jul 09, 2012 at 09:22:00AM +0100, Mel Gorman wrote:
> On Mon, Jul 09, 2012 at 11:38:20AM +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
> > forcing
On Mon, Jul 09, 2012 at 11:38:20AM +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 makes sense that compaction.o + migration.o
> isn't trivial f
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
11 matches
Mail list logo
