Christoph Lameter wrote:
On Fri, 20 Apr 2007, Ethan Solomita wrote:
cpuset_write_dirty_map.htm
In __set_page_dirty_nobuffers() you always call cpuset_update_dirty_nodes()
but in __set_page_dirty_buffers() you call it only if page->mapping is still
set after locking. Is there a reason for the difference? Also a question not
about your patch: why do those functions call __mark_inode_dirty() even if the
dirty page has been truncated and mapping == NULL?
If page->mapping has been cleared then the page was removed from the
mapping. __mark_inode_dirty just dirties the inode. If a truncation occurs
then the inode was modified.
You didn't address the first half. Why do the buffers() and
nobuffers() act differently when calling cpuset_update_dirty_nodes()?
cpuset_write_throttle.htm
I noticed that several lines have leading spaces. I didn't check if other
patches have the problem too.
Maybe download the patches? How did those strange .htm endings get
appended to the patches?
Something weird with Firefox, but instead of jumping on me did you
consider double checking your patches? I just went back, found the text
versions, and the spaces are still there.e.g.:
+ unsigned long dirtyable_memory;
In get_dirty_limits(), when cpusets are configd you don't subtract highmen
the same way that is done without cpusets. Is this intentional?
That is something in flux upstream. Linus changed it recently. Do it one
way or the other.
Exactly -- your patch should be consistent and do it the same way as
whatever your patch is built against. Your patch is built against a
kernel that subtracts off highmem. "Do it..." are you handing off the
patch and are done with it?
It seems that dirty_exceeded is still a global punishment across cpusets.
Should it be addressed?
Sure. It would be best if you could place that somehow in a cpuset.
Again it sounds like you're handing them off. I'm not objecting I
just hadn't understood that.
-- Ethan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
