All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Linton <JLinton@greshamstorage.com>
To: Mark Lobo <ntdeveloper2002@yahoo.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: Disabling block layer
Date: Mon, 26 Mar 2007 17:33:25 -0500	[thread overview]
Message-ID: <46084A35.6020700@greshamstorage.com> (raw)
In-Reply-To: <656559.33072.qm@web63001.mail.re1.yahoo.com>

Mark Lobo wrote:
> I had a question about disabling the block layer for SCSI devices. We
> have an embedded device, and it runs 2.4.30. We need to be able to
> support a lot of SCSI devices (in the thousands) for our device, and we
> talk to the devices via SG. We are facing a memory allocation problem
> after discovering a few thousand devices. For every device,  there
> seems to be a lot of memory allocated in the block layer. This memory
> includes cache memory (which IIRC is reclaimable by the kernel memory
> subsystem when it needs it) and also pages that are used for the
> alloc_pages pool.
> 
> My questions were relating to disabling the block layer for the
> devices. We always talk direct passthrough to the storage(except the
> local hard disk),  and do not need the block layer at all.

	You may consider something we experimented with here (for
performance 
reasons).. We basically recompiled one of the scsi drivers to call our 
own version of scsi_host_alloc() and then made calls to the 
queuecommand() routine directly. You then allow the kernel probe 
routines to only discover the first target with the local disk. I assume 
you know ahead of time which scsi cards your using in your system. The 
point is that you could just build a heavily modified scsi driver with 
application specific hooks.

	BTW we aren't currently doing this because in the end we got most of

what we needed by writing a driver which replaces sg and bypasses most 
of the kernel without being as invasive. In the long run we may still 
use a modified LLDD since the interfaces we depend on are changing a 
little to fast for our liking and we are not running any system devices 
on the interface cards we need to directly access.

	I'm not sure how you would go about tearing down enough of the
system 
that the device doesn't consume any resources, yet leave enough of it 
around to be accessible. I will be interested to find out what you end 
up doing.







  parent reply	other threads:[~2007-03-26 22:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-26 19:59 Disabling block layer Mark Lobo
2007-03-26 21:23 ` Douglas Gilbert
2007-03-26 21:35   ` James Bottomley
2007-03-26 22:33 ` Jeremy Linton [this message]
2007-03-28 11:24 ` Jens Axboe

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=46084A35.6020700@greshamstorage.com \
    --to=jlinton@greshamstorage.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ntdeveloper2002@yahoo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.