This thread pre-supposes that only data is being accessed.
What about when a process begins execution? Should the
size of the process determine whether the whole process
will be loaded into memory?
Back to the orginal thread... If we assume reading the
a single file. Can't our type of access change over
different areas of the program? Why limit ourselves
that specify that as long as we open the file, its
access is going to be random/sequential, whatever...
This means if we change out access pattern, do we need to
close and then re-open the file?
And I haven't even questioned about when do we expect to
need this data. Currently if we need this data immediately,
why don't we just lock the data in memory?
But don't get me wrong, I do believe in some speculation
and some stats to attempt to correctly estimate the working
set size to minimize on-demand page faults.
Mitchell Erblich
====================
Lou Grinzo wrote:
>
> The recent discussion about hinting and speculative execution
> brought to mind something I've long wondered about: Why is
> there no way to specify on a file open that you will be reading
> an entire file sequentially? If the OS knew about the caller's
> intentions at open time, it could check the available memory and
> the file's size, and if the ratio were high enough, it could read
> the whole file into a buffer, or even run a background thread to
> do read aheads.
>
> This would only apply to read-only access of existing files, obviously,
> and lacking enough memory, the OS would just ignore the flag an
> do a normal open. Given how often software processes a file in
> exactly this way, it seems like an opportunity to let the programmer
> help the OS perform an optimization.
>
> I've tried to find an example of this being tried in an OS, but come up
> empty. It's such a simple idea that I have to believe it's been looked at
> before.
>
> Lou
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/