"Williams, Dan J" writes:
> The problem is that intervening call to cond_resched(). I later want to
> inject an rcu_read_lock()/unlock() pair to allow flushing active
> dax_map_atomic() usages at driver teardown time [1]. But, I think the
> patch stands alone as a cleanup outside of that admitt
On Thu, 2015-10-22 at 17:04 -0400, Jeff Moyer wrote:
> Dan Williams writes:
>
> > dax_clear_blocks is currently performing a cond_resched() after every
> > PAGE_SIZE memset. We need not check so frequently, for example md-raid
> > only calls cond_resched() at stripe granularity. Also, in prepar
Dan Williams writes:
> dax_clear_blocks is currently performing a cond_resched() after every
> PAGE_SIZE memset. We need not check so frequently, for example md-raid
> only calls cond_resched() at stripe granularity. Also, in preparation
> for introducing a dax_map_atomic() operation that tempo
dax_clear_blocks is currently performing a cond_resched() after every
PAGE_SIZE memset. We need not check so frequently, for example md-raid
only calls cond_resched() at stripe granularity. Also, in preparation
for introducing a dax_map_atomic() operation that temporarily pins a dax
mapping move
4 matches
Mail list logo
