1. 05 Oct, 2002 31 commits
  2. 06 Oct, 2002 2 commits
  3. 05 Oct, 2002 7 commits
    • Kai Germaschewski's avatar
      kbuild: Nicer warnings · 56a8f5d4
      Kai Germaschewski authored
      Improve the warning messages when using obsolete features, kill one
      remaining user of $(list-multi)
      
      (by Sam Ravnborg)
      
      I also made O_TARGET != built-in.o an error, since compatibility code for
      that case has already been dropped 
      56a8f5d4
    • Linus Torvalds's avatar
      Merge bk://linux-bt.bkbits.net/bt-2.5 · 6cab0e06
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      6cab0e06
    • Andrew Morton's avatar
      [PATCH] clean up ll_rw_block() · 61c4b8fb
      Andrew Morton authored
      Hardly anything uses this function, so the debug checks in there are
      not of much value.
      
      The check for bdev_readonly() should be done in submit_bio().
      
      Local variable `major' was altogether unused.
      61c4b8fb
    • Andrew Morton's avatar
      [PATCH] stricter dirty memory clamping · 3669e824
      Andrew Morton authored
      The ratelimiting logic in balance_dirty_pages_ratelimited() is designed
      to prevent excessive calls to the expensive get_page_state(): On a big
      machine we only check to see if we're over dirty memory limits once per
      1024 dirtyings per cpu.
      
      This works OK normally, but it has the effect of allowing each process
      to go 1024 pages over the dirty limit before it gets throttled.
      
      So if someone runs 16000 tiobench threads, they can go 16G over the
      dirty memory threshold and die the death of buffer_head consumption.
      Because page dirtiness pins the page's buffer_heads, defeating the
      special buffer_head reclaim logic.
      
      I'd left this overshoot artifact in place because it provides a degree
      of adaptivity - of someone if running hundreds of dirtying processes
      (dbench!) then they do want to overshoot the dirty memory limit.
      
      But it's hard to balance, and is really not worth the futzing around.
      So change the logic to only perform the get_page_state() call rate
      limiting if we're known to be under the dirty memory threshold.
      3669e824
    • Andrew Morton's avatar
      [PATCH] remove page->virtual · a27efcaf
      Andrew Morton authored
      The patch removes page->virtual for all architectures which do not
      define WANT_PAGE_VIRTUAL.  Hash for it instead.
      
      Possibly we could define WANT_PAGE_VIRTUAL for CONFIG_HIGHMEM4G, but it
      seems unlikely.
      
      A lot of the pressure went off kmap() and page_address() as a result of
      the move to kmap_atomic().  That should be the preferred way to address
      CPU load in the set_page_address() and page_address() hashing and
      locking.
      
      If kmap_atomic is not usable then the next best approach is for users
      to cache the result of kmap() in a local rather than calling
      page_address() repeatedly.
      
      One heavy user of kmap() and page_address() is the ext2 directory code.
      
      On a 7G Quad PIII, running four concurrent instances of
      
      	while true
      	do
      		find /usr/src/linux > /dev/null
      	done
      
      on ext2 with everything cached, profiling shows that the new hashed
      set_page_address() and page_address() implementations consume 0.4% and
      1.3% of CPU time respectively.   I think that's OK.
      a27efcaf
    • Andrew Morton's avatar
      [PATCH] use buffer_boundary() for writeback scheduling hints · 343893e6
      Andrew Morton authored
      This is the replacement for write_mapping_buffers().
      
      Whenever the mpage code sees that it has just written a block which had
      buffer_boundary() set, it assumes that the next block is dirty
      filesystem metadata.  (This is a good assumption - that's what
      buffer_boundary is for).
      
      So we do a lookup in the blockdev mapping for the next block and it if
      is present and dirty, then schedule it for IO.
      
      So the indirect blocks in the blockdev mapping get merged with the data
      blocks in the file mapping.
      
      This is a bit more general than the write_mapping_buffers() approach.
      write_mapping_buffers() required that the fs carefully maintain the
      correct buffers on the mapping->private_list, and that the fs call
      write_mapping_buffers(), and the implementation was generally rather
      yuk.
      
      This version will "just work" for filesystems which implement
      buffer_boundary correctly.  Currently this is ext2, ext3 and some
      not-yet-merged reiserfs patches.  JFS implements buffer_boundary() but
      does not use ext2-like layouts - so there will be no change there.
      
      Works nicely.
      343893e6
    • Andrew Morton's avatar
      [PATCH] remove write_mapping_buffers() · 4ac833da
      Andrew Morton authored
      When the global buffer LRU was present, dirty ext2 indirect blocks were
      automatically scheduled for writeback alongside their data.
      
      I added write_mapping_buffers() to replace this - the idea was to
      schedule the indirects close in time to the scheduling of their data.
      
      It works OK for small-to-medium sized files but for large, linear writes
      it doesn't work: the request queue is completely full of file data and
      when we later come to scheduling the indirects, their neighbouring data
      has already been written.
      
      So writeback of really huge files tends to be a bit seeky.
      
      So.  Kill it.  Will fix this problem by other means.
      4ac833da