On Mon, 26 Nov 2001, Christoph Hellwig wrote:
> - do_generic_file_read() now takes an additional integer parameter,
> 'nonblock'. This one always is zero, though. Why do you break
> the interface?
this is just the first, more important half of O_NONBLOCK support for
block IO. Some servers (squid, TUX) rely on it for good performance.
> - there is a new global function, flush_inode_pages(). It is not
> used at all. What is this one supposed to do?
it's for TUX's logfiles - the log file can grow to many gigabytes without
polluting the pagecache. I think a new syscall should also use this:
sys_flushfile(fd,offset,size), so that user-space servers can make use of
this feature as well. If anyone is interested in actually using this new
system-call then i can add those few additional lines. (other applications
could use it as well, eg. clustered databases to invalidate database
caches - but for this purpose the function has to become a bit more
strict.)
> - file_send_actor() is no more static in mm/filemap.c. I'm perfectly
> fine with that as I will need that for the UnixWare sendv64 emulation
> in Linux-ABI, but again no user outside of filemap.c exists.
a TUX thing again, you are right, it makes no sense otherwise.
> - you change a number of parameters called 'offset' into 'index',
> this makes sense to me, but doesn't really belong into this diff..
these are cleanups triggered by a bug i did: 'offset' was not consistently
used as the byte granularity thing, it was used as a page granularity
index once, which caused a bug in an earlier version of the patch.
> - due to the additional per-bucket spinlock the pagecache size
> dramatically increases. Wouldn't it be a good idea to switch to
> bootmem allocation so very big machines still can have the full
> size, not limited by __get_free_pages failing?
for this purpose i wrote memarea_alloc() - bootmem IMO should remain a
limited boot-time helper, not a full-blown allocator.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:22 EST