public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Aboo Valappil <aboo@aboo.org>
To: linux-scsi@vger.kernel.org
Subject: Re: About SG Elements of request_buffer
Date: Wed, 25 Oct 2006 19:05:09 +1000	[thread overview]
Message-ID: <453F28C5.5000104@aboo.org> (raw)
In-Reply-To: <453223AA.50409@aboo.org>

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

Hi All,

I have posted this a while ago on strange behavior I see when "dd" opens 
and reads the disk presented by my virtual HBA. I am attaching the code 
in this email.

Basically, I have this virtual HBA which is being served by a user space 
SCSI engine. It basically transports SCSI commands out side kernel and 
get serviced by a user space scsi engine.

I have successfully implemented this using read and write system call to 
a character device. So the SCSI request buffer is copied back and forth 
user and kernel space for every request. It works alright.

Now i wanted a method of sharing SCSI request_buffer between user space 
and kernel without doing copy_to_user and copy_from_user of the 
request_buffer. I have implemented memmap and facing some challenges. I 
am memory mapping the scsi request_buffer to the user space. But i am 
facing a problem with page cache.

The SCSI device presented by my HBA is /dev/sdb (for eg:). If I open 
this device and read a block ( 512 bytes). I can see a SCSI read coming 
down my HBA. But I also a see a SCSI write later on when I close 
/dev/sdb. Up on investigation I found that it is the effect of page 
cache. When /dev/sdb opened and initiated a read, a page cache is 
already allocated. When I do memmap, I am actually mem mapping that page 
buffer to my user space SCSI engine. When the SCSI engine service the 
SCSI read, it writes the SCSI READ output to the buffer making it dirty. 
When the application  closed /dev/sdb, the kernel causes all the dirty 
pages to be written and causing the SCSI write which is what I am 
seeing. This means that for every SCSI read, i will see a SCSI write.It 
is a very strange implementation from my side. Even Xen source is doing 
the same memory mapping technique and I do not know how it avoid this 
page cache interference.

Can some one throw some lights on this for me to prevent this page cache 
interference? I have done bit of research on marking the pages/buffer 
clean after writing to the memory mapped area. But I could not find 
anything conclusive.

Thanks in advance,

Aboo


Aboo Valappil wrote:
> Hi All,
>
> Thanks for all your support for my previous posts.
>
> I have two questions.
>
> 1. Is it safe to assume that all the SG elements of request_buffer are 
> page aligned? (Except the first one and last one),  I mean, it is 
> always multiple of pages?
>
> 2. What are situations reading a scsi disk (using dd ) cause a write 
> to the disk?  When I read my virtual scsi disk using dd command, block 
> layer is generating lot of SCSI write, as well as reads. Any thoughts? 
> Besides this observation, everything is working fine.
>
> Thanks in advance.
>
> Aboo
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: scsitap.tgz --]
[-- Type: application/octet-stream, Size: 4755 bytes --]

      parent reply	other threads:[~2006-10-25  9:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-15 12:03 About SG Elements of request_buffer Aboo Valappil
2006-10-15 15:40 ` Douglas Gilbert
2006-10-15 15:53 ` James Bottomley
2006-10-25  9:05 ` Aboo Valappil [this message]

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=453F28C5.5000104@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox