Re: swap log

On Wed, Nov 28, 2001, tk wrote:
> Hello all,
>
> I was discussing the Stefan R van den Berg patches with stefan and
> directed my project toward a patch for the coss file system. I need some
> help, I'm having difficulties understanding some things. Here is the
> idee of the patches:
>
> One part of the patch is the problem of sequentialy store the swap log
> file. The idea was to reduce (in some cases eleminate) the growth of
> this file.
> - Instead of add a delete record to the swaplogfile, put a zero (empty
> marker) on the first bit of the record, and fill the next 4 bytes with a
> pointer to the next empty-list. If a record is deleted the last
> empty-list is filled with a pointer pointing to this deleted record and
> the last pointer in the chain is NULL.All record containing data get a 1
> on the first bit.
> If an empty-list pointer points to a NULL means that the file is empty
> on deleted records, so it had to create a new record in the tail of the
> swaplogfile.This will reduce the start up time of squid in case of failure.
> My question is: Is memory mapping this swap log file a speed
> improvement? Will this modyfing the swap log file really be a speed
> improvement on startup ?

The trouble, again, with mmap and friends is that access is process
synchronus - ie, if the mmap()ed memory reigon isn't fully paged
in, then accesses to "dirty" pages will end up throwing an exception
and the OS will block the process whilst the needed information
is paged in (from disk).

This kind of synchronous behaviour could cause squid to crawl to a halt
in tight memory conditions.

Now, in actual fact, the current swap logs are written to disk
via the write() method (ie not via an async IO operation) which
may block anyway. I don't know how this contributes to squid's
overall performance, but I don't think that call blocks much.

Adrian
Received on Wed Nov 28 2001 - 19:35:13 MST