Re: New TRIM/UNMAP tree published (2009-05-02)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



James Bottomley wrote:
On Sun, 2009-05-03 at 15:20 -0400, Jeff Garzik wrote:
[tangent...]

Does make you wonder if a ->init_rq_fn() would be helpful, one that could perform gfp_t allocations rather than GFP_ATOMIC? The idea being to call ->init_rq_fn() almost immediately after creation of struct request, by the struct request creator.

Isn't that what the current prep_fn actually is?

It's hard to see how ... prep_rq_fn is already called pretty early ...
almost as soon as the elevator has decided to spit out the request

prep_rq_fn is called very, very late -- from elv_next_request(), which is called from ->request_fn.

As quoted above, I'm talking about something closer to -creation- time, not -execution- time.


The creator of struct request generally has more freedom to sleep, and it seems logical to give low-level drivers a "fill in LLD-specific info" hook BEFORE the request is ever added to a request_queue.

Unfortunately it's not really possible to find a sleeping context in
there:  The elevators have to operate from the current
elv_next_request() context, which, in most drivers can either be user or
interrupt.

Sure, because that's further down the pipeline at the request execution stage. Think more like make_request time...

The ideal for REQ_TYPE_DISCARD seems to be to force a page allocation
tied to a bio when it's issued at the top.  That way everyone has enough
memory when it comes down the stack (both extents and WRITE SAME sector
will fit into a page ... although only just for WRITE SAME on 4k
sectors).

Makes sense...

	Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux