On Fri, Dec 04, 2015 at 06:15:02PM +0100, Vlastimil Babka wrote:
> On 12/03/2015 08:11 AM, Joonsoo Kim wrote:
> >It doesn't make sense that we reset defer counter
> >in compaction_defer_reset() when compaction request under the order of
> >compact_order_failed succeed. Fix it.
>
> Right.
>
>
On Fri, Dec 04, 2015 at 06:15:02PM +0100, Vlastimil Babka wrote:
> On 12/03/2015 08:11 AM, Joonsoo Kim wrote:
> >It doesn't make sense that we reset defer counter
> >in compaction_defer_reset() when compaction request under the order of
> >compact_order_failed succeed. Fix it.
>
> Right.
>
>
On 12/03/2015 08:11 AM, Joonsoo Kim wrote:
It doesn't make sense that we reset defer counter
in compaction_defer_reset() when compaction request under the order of
compact_order_failed succeed. Fix it.
Right.
And, it does make sense that giving enough chance for updated failed
order
On 12/03/2015 08:11 AM, Joonsoo Kim wrote:
It doesn't make sense that we reset defer counter
in compaction_defer_reset() when compaction request under the order of
compact_order_failed succeed. Fix it.
Right.
And, it does make sense that giving enough chance for updated failed
order
It doesn't make sense that we reset defer counter
in compaction_defer_reset() when compaction request under the order of
compact_order_failed succeed. Fix it.
And, it does make sense that giving enough chance for updated failed
order compaction before deferring. Change it.
Signed-off-by: Joonsoo
It doesn't make sense that we reset defer counter
in compaction_defer_reset() when compaction request under the order of
compact_order_failed succeed. Fix it.
And, it does make sense that giving enough chance for updated failed
order compaction before deferring. Change it.
Signed-off-by: Joonsoo
6 matches
Mail list logo
