From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q1TDLfrd025675 for ; Wed, 29 Feb 2012 14:21:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkDAPAlTk/U4367k2dsb2JhbABDgwGCJq43IgEBAQEJCQsJFAMkgXcBAQQBIwRFBgQDEAsaAiYCAlcGEwkSh2gJB6crkkCBL4g+gwwOAwkEBhECAgMBAgIDBAYPCQMHBxMBhRIDBTQCDAQDCRSCHYEWBI0/jV+NE4Fb X-IronPort-AV: E=Sophos;i="4.73,502,1325458800"; d="scan'208";a="146702486" Received: from moutng.kundenserver.de ([212.227.126.187]) by mail1-smtp-roc.national.inria.fr with ESMTP; 29 Feb 2012 14:21:35 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-212-228.pools.arcor-ip.net [94.219.212.228]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M6xID-1SO7ty01qv-00x4N3; Wed, 29 Feb 2012 14:21:35 +0100 Received: from [192.168.178.17] (546BF816.cm-12-4d.dynamic.ziggo.nl [84.107.248.22]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 8A11AC00CC; Wed, 29 Feb 2012 14:21:34 +0100 (CET) From: Gerd Stolpmann To: Goswin von Brederlow Cc: caml-list@inria.fr In-Reply-To: <87d38y0z80.fsf@frosties.localnet> References: <87y5rmemr6.fsf@frosties.localnet> <1330463367.2826.96.camel@thinkpad> <87d38y0z80.fsf@frosties.localnet> Content-Type: text/plain; charset="UTF-8" Date: Wed, 29 Feb 2012 14:21:33 +0100 Message-ID: <1330521693.2826.146.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:3R9QaXyxXomxNq9Gq9iN7LidiTBb7pyYTFzGA0AaWR+ tpYC10K69wY/I+Bw4Z+4dAmMME+QuoQX2R2rxmGfcyZV2llQzj LuC6SA8rV//hSe2ddMv/bKbF0k98b8ndovJsQkXPHK9eOWke19 ToJeSEaQv/SiWZlYwTdVRnKyAolTLS7W54V9Clq0gzmhZsQXCD oKfTnMtcrNDgPLjeWlofc1ttpLeev1qa6oBLisp6KIg0nu60/7 Do10DvSwYDpPnQt4228i5YfSvgHYAa/bUTUQfTBhwbbtboRa3g 0BHwBntFGe8DYQ3QQhWREk9mKhLgmzaP8n/yglLXtu/qv8w1rW 3rKKY2LPS1gDWLEPwwyDKMq8IE33gnoRYU4GGax2X Subject: Re: [Caml-list] Bigarray question: Detecting subarrays, overlaps, ... Am Mittwoch, den 29.02.2012, 10:23 +0100 schrieb Goswin von Brederlow: > >> For efficiency each request stores all its data in a single > >> Bigarray.Array1. For reasons of the RAID implementation large requests > >> are split into 4k chunks using Bigarray.Array1.sub and grouped into > >> stripes. The stripes are then acted upon independently until all stripes > >> involved in a request are finished. Then the request is completed. > >> > >> Now I get a problem when 2 requests come in that overlap. Say I get a > >> write request for blocks 0 - 6 and a read request for blocks 4-9 in > >> that order. Since I already have the data for block 4-6 in memory from > >> the write request I do not want to reread them from disk. On the stripe > >> level the data looks like this: > >> > >> |W0 W1 W2 W3 W4 W5 W6 . . . | write 0-6 > >> | W4 W5 W6 R7 R8 R9 | read 4-9 > >> > >> For the read request I need to copy W4-6 to R4-6 or send out W4-6 + R7-9 > >> in two writes. I think I would like to avoid sending each stripe chunk > >> out seperately. > > > > Why not? This seems to be an elegant solution, and I don't see why this > > should make the accesses slower. The time for the extra context switches > > in negligible compared to the disk accesses. > > A lot of the time data will just move between caches so disk speed is > secondary. And sending each chunk seperately would mean up to 32 context > switches instead of 1. And writing to a socket in chunks can lead to the > data being send out in frames less than the MTU which would be > wastefull. So I think there is some gain in limiting this. A context switch takes less than a microsecond on typical hardware, including the time for rebuilding the TLB from the page table. Sending a 4K block over gigabit network takes more than 30 times longer. I doubt you can gain from combining several chunks. Sending the data in frames less than the MTU can normally only happen when you disable the Nagle algorithm (did you?). And even then, you only need to fill the TCP buffer faster than the network can transport the data to avoid it. > >> On the other hand I could implement (p)readv() and > >> (p)writev() stubs. > >> > >> Anyway, my question now is how to detect which subarrays in the stripes > >> are part of a common larger array? Do I need to write my own C stub that > >> looks into the internas of the arrays to see if they share a common > >> ancestor? I think that would be preferable to tracking the origin of > >> each subarray myself. > > > > Yes, subarrays are tracked, but this feature exists only to catch the > > right moment for unmmapping bigarrays (if needed). As far as I remember, > > this is not tracked as a sub/super relationship, but the bigarrays > > accessing the same buffer share then the same buffer descriptor, and > > when the use count drops to 0, the buffer is finally destroyed. So, you > > cannot say which bigarray is the original one, and it can even be that > > the original bigarray is already deallocated but the backing buffer is > > not yet. > > All subarrays share a struct caml_ba_proxy, as you say to catch the > right moment for unmmapping bigarrays. So two subarrays are part of the > same bigarray if they have the same proxy object. That seems like an > easy enough test. Which one is the original bigarray doesn't matter, at > least to me. > > >> On a similar note how does Bigarray.Array1.blit handle arrays that are > >> part of the same larger array and overlap? > >> > >> ---------------------------------------------------------------------- > >> I'm missing functions like: > >> > >> val super : ('a, 'b, 'c) t -> ('a, 'b, 'c) t -> ('a, 'b, 'c) t > >> Create a merged sub-array of 2 adjacent sub-arrays of the same > >> big array. > > > > This function would be possible to implement. The requirement would be > > that both bigarrays use the same buffer descriptor. > > > >> val same_parent : ('a, 'b, 'c) t -> ('a, 'b, 'c) t -> bool > >> True if the 2 (sub-)arrays are part of the same big array. > > > > I would not call it "same_parent", but "same_backing_buffer". > > Maybe "related" would be better? > > >> val offset : ('a, 'b, 'c) t -> int > >> Offset of the sub-array in the underlying big array. > > > > I think this information is in the current implementation not available. > > As buffer sharing is also possible after reshaping, this is also not > > meaningful in the general case. > > offset = array->data - array->proxy->data; > > After reshaping the offset would be the offset into the original array > after reshaping that too. > > For me the offset would be relevant to see which 2 sub arrays could be > merged with "super" above. That it wouldn't always be meaningfull I > could accept. What I did not understand up to now: It is really easy to keep all this information in a helper data structure. Why extend Bigarray? Gerd > > > Gerd > > MfG > Goswin > -- ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. ------------------------------------------------------------