[lkml]   [1996]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: New kernel proc interface

On 01-Nov-96 wrote:
>> The problems described above are easily solved by allowing the
>> proc routines to write out all their data in one shot, and
>> caching that data for the user programs.
>Not always. The ip routing tables could be 40,000 routes or more. Which at
>80 bytes a route is 3.2Mb of data to cache !

Is that really a problem? Isn't the trade-off worth the RAM
requirements? I knew that this would be brought up when I
decided that caching the data was necessary, but it is a
reasonable approach. If you want the data pulled out of
proc to be consistent, atomicity is necessary.

Besides, the data is cached only while the file is held open.
When the file is closed, all that memory is freed. 3.2MB is
a pitance today. Anyone that is using 40K routes can afford
the US$12 for another 4MB.

The approach the kernel uses now gives a close approximation
(with possible duplicate or missing information) of the current
kernel state. And it really isn't the "current" kernel state,
which implies a discrete point in time, but rather a fuzzy
image of the kernel state over a period of time. How useful can
this be?

The current proc code was the best solution when RAM was limited.
Today's systems have much more RAM than in the past. Hacks like
this should be elimnated now that the majority of systems have
the resources to do "the right thing." (TM)

If this is really an issue, implimenting backwards compatibilty
for memory critical proc routines is trivial.


 \ /
  Last update: 2005-03-22 13:37    [W:0.138 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site