On Thu, Mar 26, 2015 at 05:13:13PM +0900, Sergey Senozhatsky wrote:
> On (03/26/15 16:39), Minchan Kim wrote:
> > Hello Sergey,
> >
> > Sorry for slow response.
> > I am overwhelmed with too much to do. :(
> >
>
> Hello,
> sure, no problem.
>
> > > > diff -puN mm/zsmalloc.c~zsmalloc-remove-extra-cond_resched-in-__zs_compact mm/zsmalloc.c
> > > > --- a/mm/zsmalloc.c~zsmalloc-remove-extra-cond_resched-in-__zs_compact
> > > > +++ a/mm/zsmalloc.c
> > > > @@ -1717,8 +1717,6 @@ static unsigned long __zs_compact(struct
> > > > struct page *dst_page = NULL;
> > > > unsigned long nr_total_migrated = 0;
> > > >
> > > > - cond_resched();
> > > > -
> > > > spin_lock(&class->lock);
> > > > while ((src_page = isolate_source_page(class))) {
>
> >
> > If we removed cond_resched out of outer loop(ie, your patch), we lose
> > the chance to reschedule if alloc_target_page fails(ie, there is no
> > zspage in ZS_ALMOST_FULL and ZS_ALMOST_EMPTY).
>
>
> in outer loop we have preemption enabled and unlocked class. wouldn't that help?
> (hm, UP system?)
It depends on preemption model. If you enable full preemption, you are right
but if you enable just voluntary preemption, cond_resched will help latency.
Thanks.
--
Kind regards,
Minchan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>