Re: efficacy of Linux w/o swap

phil-news-nospam_at_ipal.net
Date: 05/16/05 

Date: 16 May 2005 14:37:36 GMT

On Mon, 16 May 2005 07:02:33 -0400 James McIninch <james.mcininch.nospam@comcast.net> wrote:

| Caching is supposed to happen, and this does not affect performance.

It has affected performance quite severely. I'm working up a viable
test to evaluate that before I buy the hardware for this project.

| Swapping should happen to very old pages during idle time. However, as you
| said, sometimes this isn't desirable when the latency of a page reload is
| too high. You can selectively lock pages into RAM using memlock() (assuming
| you've got the source code) and then simply be careful not to exhaust your
| RAM.

When the amount of data being written is massive, it seems that almost all
process VM pages are old. The problems were almost always noticed at about
a point when the amount of data written was between 4 times and 8 times the
amount of RAM. On a 256 MB machine, things started to slow down somewhere
between 1 GB and 2 GB of writing. On a 512 MB machine, this happened around
2 GB to 4 GB. Clearly not all of the written data can be cached. Perhaps
this is the point where the kernel keeps trying to get more and more pages
that the impact starts to degrade the writing process itself.

| Swap is not at all necessary, assuming that you've got sufficient RAM.
| You could use O_DIRECT to write data to disk, but you'll torpedo your
| performance as a result. Keep in mind that the rigorous caching and
| buffering performed by the kernel is generally the optimal strategy.
| Writing directly to disk will substantially decrease performance.

In an earlier thread I asked about finding a way to simply defeat caching
and O_DIRECT was suggested on the basis that caching in the drive hardware
itself would smooth over the latency due to the process being blocked in
write() for each operation. I set up a test and this did seem to keep the
disk drive solidly writing. Performance for the first 3/4 of an IDE disk
was well over the level I need to capture video uncompressed. Not using
the last 1/4 won't be that big an issue ... I can use that space for file
backups during down time. Because the speed gradually decreased as the
position went from beginning to end of the disk (120 GB IDE), it does not
appear that IDE and its DMA was the speed limiting factor, but rather,
the drive itself ... it's change in track pitch ... was. New disks at the
size of 300 GB or more should more likely max out the IDE speed capacity,
which for now seems to be all I need. My only worry is whether the DMA
capacity will still be there when I'm simultaneously capturing via Firewire
and writing that data to disk.

Anyway, O_DIRECT does not kill performance at all, if the process can stay
busy with it. But, if the process is doing both read() and write(), that
could cause problems because it would be stuck in write() and can't read()
for all that time. So what I am thinking is either 2 threads, or 2 processes
with a shared chunk of anonymous memory, one doing the reading and the other
doing the writing, with some means of simply syncronizing between them like
a simple pipe over which is periodically written an index marker. If the
writer has nothing left to write, it can safely block reading a pipe to get
the next index in the ring buffer and when it gets it, write all that data. 

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

Relevant Pages

  • Re: Overlapped IO with error 0x800705AD
    ... could also get cached data without an access to an actual disk. ... and it's why I tried to disadvantage caching by avoiding to access preloaded ... are two, one high level object cache for perfs, and one low level sector ... And I have best perfs by queueing more requests by thread (best ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Concurrently streaming a file to HttpResponse and file IO
    ... caching" borders on paradoxical -- it's not as if the SQL database isn't stored on disk. ... Please make sure you've eliminated possible sources of slowness in the blob solution first, like disk fragmentation, a database server that's running out of memory or I/O bandwidth, network congestion, poorly chosen network settings, DB drivers with known performance issues and probably other things I'm forgetting. ... Note that, as with all caching strategies, you're facing concurrency and data integrity issues w.r.t. updates to the blob data. ... then check whether a "streaming register" contains information about the current file currently being streamed to disk. ...
    (microsoft.public.dotnet.languages.csharp)
  • Temporary lock-up under heavy write, MegaRAID RAID-5
    ... LSI Logic MegaRAID 320-1, 64MB cache ... when writing very large files. ... disk write access, actually). ... The RAID controller is currently set to "write-through". ...
    (Debian-User)
  • Re: X-CD Roast question again please
    ... Using generic SCSI-3/mmc CD-R driver. ... Disk sub type: Medium Type A, ... ATIP start of lead in: -11318 ... writing 152 KB of pad data. ...
    (RedHat)
  • Re: Not able to disable disk write cache
    ... > I did all previous tests with NTFS with compression. ... > Now I prepared a CF disk with FAT and tested again ... > FlushFileBuffers, then cut power off, reboot, compare ... >> Anyhow you can't do anything to disk internal caching trough MS ...
    (microsoft.public.windowsxp.embedded)