Re: vblade-22-rc1 is first release candidate for version 22

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

 



On 07/13/2014 06:23 PM, David Leach wrote:
> So I do find it interesting to have a configuration to limit the size 
> of the read/write request but it seems like it would be useful to 
> understand the side affects on why someone would want to do this. 
> Catalin suggested that reducing the size of the jumbo frames decreases 
> latency and improves boot-times and said that the system "feels more 
> response". This is were I have a problem though because something 
> "feeling" more responsive is not very satisfying. It would be better 
> to have some hard numbers behind what this change does.

Yes, I agree.  If Catalin posts the patch here, then perhaps any 
interested parties would be able to gather some data.

[Leach correctly notes that some jumbos carry ...]
> 17 sectors of data per request.

There is often a lot going on there.  For example, if the initiator host 
is using a filesystem, then writes will dirty pages of memory that are 
buffering the data from the AoE device.  The virtual memory subsystem 
will flush that data when it gets around to it, using whatever chunks it 
likes, then the block layer will probably consolidate or split the I/O 
as it likes inside the I/O scheduler, and only then will the aoe 
initiator get the data.

But the aoe driver will set up network buffers (sk_buff structures) that 
point right into the memory associated with the I/O.  The network card 
itself often does the transfer from RAM into the card and vice versa.  
I'm not sure there's a significant penalty paid for telling the NIC to 
DMA seventeen sectors.  It would be a good test to do in the aoe driver 
with a few different representative NICs.

Further, on the target side, there's no guarantee that the target will 
do the I/O in exactly the same chunks that appear in the AoE packets.  
Even disk drives have elevator algorithms scheduling I/O from write buffers.

I agree that test results here would be interesting, but a big "Your 
Mileage May Vary" should accompany the results.

-- 
   Ed

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Aoetools-discuss mailing list
Aoetools-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/aoetools-discuss




[Index of Archives]     [Linux ARM Kernel]     [Linux SCSI]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux