mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Matthew Wilcox <matthew@wil.cx>,
	Jens Axboe <jens.axboe@oracle.com>,
	Boaz Harrosh <bharrosh@panasas.com>,
	Hugh Dickins <hugh@veritas.com>,
	Matthew Wilcox <willy@linux.intel.com>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-scsi@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
	Mark Lord <lkml@rtr.ca>
Subject: Re: New TRIM/UNMAP tree published (2009-05-02)
Date: Sun, 03 May 2009 14:47:47 -0500	[thread overview]
Message-ID: <1241380067.5596.103.camel@mulgrave.int.hansenpartnership.com> (raw)
In-Reply-To: <49FDEE64.5090302@garzik.org>

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?

> I obviously have not thought in depth about this, but it does seem that 
> init_rq_fn(), called earlier in struct request lifetime, could eliminate 
> the need for ->prepare_flush, ->prepare_discard, and perhaps could be a 
> better place for some of the ->prep_rq_fn logic.

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

> 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.

The way the block layer is designed is to pull allocations up the stack
much closer to the process (usually at the bio creation point) because
that allows the elevators to operate even in memory starved conditions.
If we pushed the allocation down into the request level, we'd need some
type of threading (bad for performance) and the request processing would
stall when some GFP_KERNEL allocation went out to lunch finding memory.

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).

James



  parent reply	other threads:[~2009-05-03 19:48 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-02 14:37 [PATCH 1/5] Block: Discard may need to allocate pages Matthew Wilcox
2009-04-02 14:37 ` [PATCH 2/5] Make DISCARD_BARRIER and DISCARD_NOBARRIER writes instead of reads Matthew Wilcox
2009-04-02 14:37   ` [PATCH 3/5] ata: Add TRIM infrastructure Matthew Wilcox
2009-04-02 14:37     ` [PATCH 4/5] ide: Add support for TRIM Matthew Wilcox
2009-04-02 14:37       ` [PATCH 5/5] libata: " Matthew Wilcox
2009-04-02 17:20         ` Mark Lord
2009-04-02 17:55           ` Matthew Wilcox
2009-04-16 20:25         ` Mark Lord
2009-04-17 19:44           ` Mark Lord
2009-04-02 15:58       ` [PATCH 4/5] ide: " Sergei Shtylyov
2009-04-02 16:28         ` Matthew Wilcox
2009-04-02 16:38           ` Sergei Shtylyov
2009-04-02 16:51             ` Matthew Wilcox
2009-04-02 19:37               ` Bartlomiej Zolnierkiewicz
2009-04-07 21:38                 ` Bartlomiej Zolnierkiewicz
2009-04-07 22:15                   ` Matthew Wilcox
2009-04-07 22:26                     ` Jeff Garzik
2009-04-07 22:35                     ` Bartlomiej Zolnierkiewicz
2009-04-07 17:20       ` Jeff Garzik
2009-04-07 17:57         ` Mark Lord
2009-04-07 18:10           ` Markus Trippelsdorf
2009-04-07 19:58             ` Mark Lord
2009-04-08  7:14               ` Markus Trippelsdorf
2009-04-08 14:25                 ` Mark Lord
2009-04-08 14:33       ` Mark Lord
2009-04-08 14:44         ` Dongjun Shin
2009-04-08 14:59         ` Jeff Garzik
2009-04-08 15:50           ` Mark Lord
2009-04-02 15:55     ` [PATCH 3/5] ata: Add TRIM infrastructure Sergei Shtylyov
2009-04-02 16:18       ` Matthew Wilcox
2009-04-02 16:32         ` Sergei Shtylyov
2009-04-02 16:47           ` Matthew Wilcox
2009-04-07  0:02     ` Jeff Garzik
2009-04-05 12:28 ` [PATCH 1/5] Block: Discard may need to allocate pages Boaz Harrosh
2009-04-06 20:34   ` Matthew Wilcox
2009-05-03  6:11   ` Matthew Wilcox
2009-05-03  7:16     ` New TRIM/UNMAP tree published (2009-05-02) Matthew Wilcox
2009-05-03 13:07       ` Hugh Dickins
2009-05-03 14:48         ` Matthew Wilcox
2009-05-03 15:02           ` Boaz Harrosh
2009-05-03 15:42             ` Matthew Wilcox
2009-05-03 16:34               ` Boaz Harrosh
2009-05-03 18:34                 ` Jeff Garzik
2009-05-03 18:40                   ` Jeff Garzik
2009-05-03 19:04                     ` James Bottomley
2009-05-03 19:20                       ` Jeff Garzik
2009-05-03 19:37                         ` James Bottomley
2009-05-04 14:03                           ` Douglas Gilbert
2009-05-04 14:40                             ` James Bottomley
2009-05-04 15:11                               ` Douglas Gilbert
2009-05-04 15:23                                 ` James Bottomley
2009-05-03 19:47                         ` James Bottomley [this message]
2009-05-03 22:47                           ` Jeff Garzik
2009-05-04 15:28                             ` Boaz Harrosh
2009-05-03 21:48                   ` Matthew Wilcox
2009-05-03 22:54                     ` Jeff Garzik
2009-05-03 18:48               ` Bartlomiej Zolnierkiewicz
2009-05-03 15:05           ` Hugh Dickins
2009-04-17 21:23 ` [PATCH 1/5] Block: Discard may need to allocate pages Mark Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1241380067.5596.103.camel@mulgrave.int.hansenpartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=bharrosh@panasas.com \
    --cc=bzolnier@gmail.com \
    --cc=hugh@veritas.com \
    --cc=jeff@garzik.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --cc=matthew@wil.cx \
    --cc=willy@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®