All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aboo Valappil <aboo@aboo.org>
To: linux-scsi@vger.kernel.org
Subject: About sg_tablesize in 2.6 kernel
Date: Sun, 01 Oct 2006 21:22:42 +1000	[thread overview]
Message-ID: <451FA502.1070207@aboo.org> (raw)

Hi All,

I am not sure if this is the right place to ask these questions. I am 
new to this list. Does this list offer any help to device driver 
developers? I appreciate if any one could give an answer to these 
questions.

1. In 2.6 kernel, even if I set the sg_tablesize to SG_NONE, the 
mid-layer is still queuing commands with use_sg=1. There is no way to 
disable this SG at all? I do not need a sg_table as I do not use any DMA 
or anything else. With SG_NONE, the use_sg is always set to 1 and the IO 
size queued by mid layer is only 512 bytes and decreases the throughput 
very badly.

2. One of the challenge I am facing is that the scatterlist structure is 
changed. There is no virtual address, but they replaced this with a page 
and offset fields. Since I need only the virtual addresses for the 
actual buffer (No DMA), I am using the following method to calculate the 
virtual address.

address=page_address(sg[i].page) + sg[i].offset;

Is this the right way? I am assuming that sg[i].page will be mapped in 
to kernel address space as this address is created by SCSI mid-layer. Is 
that right? Or do I have to use kmap? I tried replacing page_address 
with kmap/kunmap. But as soon as call kunmap to unmap, the kernal 
panics! Any thoughts?

3. Do I have to disable bottom halves before calling scsi_done()? It 
seems that the kernel panics when I call scsi_done if I use spin_lock 
instead of spin_lock_bh(). This is one of my spin_locks created for 
protecting a data structure.


Thanks in advance,

Aboo


             reply	other threads:[~2006-10-01 11:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-01 11:22 Aboo Valappil [this message]
2006-10-01 18:43 ` About sg_tablesize in 2.6 kernel Arjan van de Ven
2006-10-02  2:33   ` Aboo Valappil
2006-10-02  3:29     ` Douglas Gilbert

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=451FA502.1070207@aboo.org \
    --to=aboo@aboo.org \
    --cc=linux-scsi@vger.kernel.org \
    /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.