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
On Mon, Jul 9, 2012 at 10:12 PM, Minchan Kim minc...@kernel.org 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
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
*
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
> > >
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
>
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)) {
> > > +
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
> >
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
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 for
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
forcingly[1].
On Mon, Jul 09, 2012 at 05:46:57PM +0900, Minchan Kim wrote:
SNIP
+#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_once(WARNING:
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:
SNIP
+#if defined(CONFIG_DEBUG_VM) !defined(CONFIG_COMPACTION)
+static inline void check_page_alloc_costly_order(unsigned int order)
+{
+ if
On Mon, 09 Jul 2012 at 08:46 GMT, Minchan Kim minc...@kernel.org 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
On Mon, Jul 09, 2012 at 09:50:48PM +0900, Minchan Kim wrote:
SNIP
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, Jul 09, 2012 at 02:05:51PM +0100, Mel Gorman wrote:
On Mon, Jul 09, 2012 at 09:50:48PM +0900, Minchan Kim wrote:
SNIP
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
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 minc...@kernel.org 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
On Mon, 9 Jul 2012 22:19:42 +0900
Minchan Kim minc...@kernel.org 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
*
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
22 matches
Mail list logo
