Re: memory mapped store entries

> > Lock the page with a semaphore.
>
> Semaphore's can be really expensive. On big MP machines with async IO
> and high loads, this needs to be as cheap as reasonably possible.

        I was talking about at the kernel level. Given that this could be
a spinlock access to a test on whether the page was in transition and therefore
place this process onto a sleep queue pending that IO completion would be the
way an efficient kernel would do this IF that was the behaviour that it
was trying to achieve.

        This is irrevelant however to the discussion on what mmap() actually
does and how it affects a process accessing file mmap'ed pages.

> mlock is expensive, so is mmap.

        We're talking about doing these operations once at startup. After
that we don't care. The map exists, the lock exists. After startup,
overhead for mmap and mlock is irrelevant.

> > That's pretty low load. I'm talking about 5000 HTTP requests per
> > minute at peak loads across 80Gb cache swaps. The mmap() system
> > you propose will save a fair chunk of memory on that.
>
> Ouch... Bang bang the Packet Man.
>
> What OS/mem/config are you running?

Currently: Solaris 2.5.1/1G RAM/12x4Gb spindles for 40Gb usable/100Mb ENet/
           dual 250MHz UltraSPARCII CPUs in Sun U450 Chassis
Peak at 4000 HTTP req/min, 48000 ICP req/min
We have 1 machine like the above plus 3 Sun Ultra 2's with dual 167MHz CPUs

Soon: Solaris 2.6/1.5G RAM/24x4Gb spindles for 80Gb usable/100Mb Enet/
         dual 250MHz UltraSPARCII CPUs in Sun U250 Chassis
Estimated Peak at 5000 HTTP req/min, 60000 ICP req/min
Will have 4 machines with this config within 6 weeks.

We run parent caches for somewhat more than 100 ISPs in Australia.

Stew.

-- 
Stewart Forster (Snr. Development Engineer)
connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust.
Email: slf@connect.com.au   Phone: +61 3 9251-3684   Fax: +61 3 9251-3666