Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 05/18/2010 08:58 AM, Mark Woodward wrote: > > A few points:=20 > (1) The disk block I am requesting will never be in cache unless I have= requested it. > (2) A "good database" i.e. not mySQL, something like Oracle, DB2, Postg= reSQL, etc. do their own caching and manage their own data access. Oracle= still has their own device level access system. > (3) A "few" (4) milliseconds shaved off a function that is run half a m= illion to a million times is between 1/2 hour and an hour of wall clock t= ime. That is important. > (4) If asynchronous I/O is not used, then I will *always" have the wors= t case scenario of purely sequential reads. > > =20 Mark, I think that what you want to do is certainly possible, but you are going to need to use, not only open(2), seek(2), read(2), but also ioctl(2). You'll probably need to look at the actual driver code to see exactly what each ioctl does. Without subverting the driver, you could achieve what you want, but you could also subvert the driver if you want to. Another thing you may want to do is to look at mmap(2) also.=20 Essentially, for those who might be unfamiliar with mmap(2) you can use this to system call to map a file into virtual memory. The downside of this is that you can get into memory issues, but you will do this with your disk caching. The nice thing about mmap(2) whether you use it to map a file, or just manage your memory, is that you allocate on page boundaries. In contrast, malloc(3) give you small chunks and is uses various schemes such as the classic brk(2) and sbrk(3) to allocate virtual memory. I don't know the actual underlying scheme malloc(3) uses in Linux, but some versions utilize mmap(2) in addition to sbrk(2) and brk(2). I assume that the files you would be using would be a large database where an mmap(2) would be impractical, but mmap(2) for your memory management might be much better than using malloc(2) or sbrk(2).=20 Note that in C++, the new operator is normally layered directly on malloc(3), so if you are writing in C++, you do have to be a bit careful that you don't subvert sbrk(2), brk(2). Again a quick explanation. sbrk(2) allocates virtual memory sequentially from the top of the process data segment until it hits a barrier. In contrast, mmap(2) can allocate anywhere in your virtual memory space, including the region above where your brk(2) is effectively blocking sbrk(2), brk(2) from allocating any more. I've written code to specifically do this to test Purify and a new version of malloc(3). In general, there will not be a conflict between pages allocated by mmap(2) and sbrk(2), but it can happe= n. --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |