Hello, Andrew.
On Thu, Jul 31, 2014 at 06:16:56PM -0700, Andrew Morton wrote:
> Yet nowhere in either the changelog or the code comments is it even
> mentioned that this allocator is unreliable and that callers *must*
> implement (and test!) fallback paths.
Hmmm, yeah, somehow the atomic behavior
On Thu, 31 Jul 2014 20:44:38 -0400 Tejun Heo wrote:
> Hello, Andrew.
>
> On Thu, Jul 31, 2014 at 6:03 PM, Andrew Morton
> wrote:
> > I don't think we should add facilities such as this. Because if we do,
> > people will use them and thereby make the kernel less reliable, for
> > obvious reason
Hello, Andrew.
On Thu, Jul 31, 2014 at 6:03 PM, Andrew Morton
wrote:
> I don't think we should add facilities such as this. Because if we do,
> people will use them and thereby make the kernel less reliable, for
> obvious reasons.
>
> It would be better to leave the nasty hack localized within
>
On Fri, 18 Jul 2014 16:08:04 -0400 Tejun Heo wrote:
> percpu allocator requires sleepable context for allocations. Most use
> cases are fine with the requirement but blk-throttle currently
> implements its own asynchronous allocation mechanism to allow
> initiating allocation from atomic context
On Fri, Jul 18, 2014 at 04:08:04PM -0400, Tejun Heo wrote:
> Hello,
>
> So, I have another case where percpu allocation needs to be performed
> from an atomic context (also on the IO path), so I wrote up a simple
> percpu alloc cache which is filled asynchronously and replaced
> blk-throttle's cus
Hello,
So, I have another case where percpu allocation needs to be performed
from an atomic context (also on the IO path), so I wrote up a simple
percpu alloc cache which is filled asynchronously and replaced
blk-throttle's custom implementation with it.
I still think it's quite unlikely that we
6 matches
Mail list logo
