On Wed, Jan 12, 2005 at 02:43:20PM +0200, Tzahi Fadida wrote: > Lets see if I understand, a dirtied buffer is not a regular > file read/write related but only a buffer I allocated in a process > using malloc, etc... that was changed and needed to be > returned to the vm swap file.
Nope. Short explanation follows, and I suggest you consult a good book on the subject, such as Robert Love's Linux Kernel Development. In 2.2 era, there used to be two main caches. A page cache, which cached pages, and a buffer cache, which cached buffers. The page cache held memory pages, and the buffer cache held disk buffers. This lead to the most annoying situation where the same information, a disk block that was read into a page in memory, could exist in both caches. Starting with 2.4, the two caches have been united, and we only have the page cache. However, the kernel still deals with buffers, which are "a mapping of a disk block onto a page". > The question is, how do I know its my process dirtied buffer > being written. for example, how do I find out that > kupdated: READ block 475474/2 on 03:05 > or > kupdated: WRITE block 180266/2 on 03:05 > was caused by my program memory manipulations. > p.s: the 475474 is bh->b_rsector in the code which probably > literaly means the sector on a disc. Correct, and 03:05 is the major:minor device number (/dev/hda5 in this case). I haven't looked at the laptop mode code; but I imagine you could correlate block reads by your program with later block writes by the writeback daemons (pdflush in 2.6, kupdated and bdflush in 2.4). As to why kupdated is doing READs, interesting question... Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/
signature.asc
Description: Digital signature
