Chris
> On 04/02/2015, at 18.35, Roman Leventov <[email protected]> wrote: > > On 4 February 2015 at 23:02, Chris Vest <[email protected]> wrote: >> >> >> If we use official APIs, then there’s the overhead. All the pages would now >> also hold on to buffers and cleaners. If I remember correctly, we currently >> spend 64 bytes per page (on 32 bit JVMs, or when compressed oops are >> enabled), plus some overhead from organising structures in the page cache. >> This would increase a good deal. If we instead use FileChannelImpl.map0, >> then the memory overhead would stay the same, and that might be interesting. >> I’d have to research how it influences error handling, though. But this only >> saves us a memcpy during page faults, doesn’t it? That doesn’t sound like a >> big win. > memcpy is indeed should be very fast, but you also save physical memory > usage, because same disk bytes are kept in both OS file caches and your > buffers. If there's memory pressure, then the OS will only see us touch the page once, and then it'll get evicted easily. I'd like to fadvise that we don't need the pages after we've ingested them, but I haven't found a good way to do that from Java. I'm guessing it'd speed up future page faults as free pages are more likely to be readily available, so we don't have to spend time evicting them on demand, as part of the page fault. > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
