Re: Process Scheduling Issue using sg/libata

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

 



On 11/18/07, Mark Lord <liml@xxxxxx> wrote:
> Fajun Chen wrote:
> >..
> > I verified your program works in my system and my application works as
> > well if changed accordingly. However, this change (indirect IO in sg
> > term) may come at a performance cost for IO intensive applications
> > since it does NOT utilize mmaped buffer managed by sg driver.  Please
> > see relevant sg document below:
> > http://sg.torque.net/sg/p/sg_v3_ho.html#id2495330
> > http://sg.torque.net/sg/p/sg_v3_ho.html#dmmio
> > As an example, sg_rbuf.c in sg3_util package uses SG_FLAG_MMAP_IO flag
> > in SG_IO. Please see source code attached. I also noticed that
> > MAP_ANONYMOUS is NOT used in mmap() call in sg_rbuf.c, which may not
> > be desirable as you pointed out in previous emails. So this brings up
> > an interesting sg usage issue: can we use MAP_ANONYMOUS with
> > SG_FLAG_MMAP_IO flag in SG_IO?
> ..
>
> The SG_FLAG_MMAP works only with /dev/sg* devices, not /dev/sd* devices.
> I don't know which kind you were trying to use, since you still have
> not provided your source code for examination.
>
> If you are using /dev/sg*, then you should be able to get your original mmap()
> code to work.  But the behaviour described thus far seems to indicate that
> your secret program must have been using /dev/sd* instead.
>
As a matter of fact, I'm using /dev/sg*.  Due to the size of my test
application, I have not be able to compress it into a small and
publishable form. However, this issue can be easily reproduced on my
ARM XScale target using sg3_util code as follows:
1. Run printtime.c attached,  which prints message to console in a loop.
2. Run sgm_dd (part of sg3_util package, source code attached) on the
same system as follows:
>sgm_dd if=/dev/sg0 of=/dev/null count=10M bpt=1
The print task can be delayed for as many as 25 seconds. Surprisingly,
I can't reproduce the problem in an i386 test system with a more
powerful processor.

Some clarification to MAP_ANONYMOUS option in mmap(). After fixing a
bug and more testing, this option seems to make no difference to cpu
load. Sorry about previous report. Back to the drawing board now :-)

Thanks,
Fajun

Attachment: printtime.c
Description: Binary data

Attachment: sgm_dd.c
Description: Binary data


[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