RE: How can TUX user module get notified when a page is removed from cache?

On Tuesday, April 02, Ingo said "[feel free to send me an email if you have
trouble
implementing this.]"  :-)

Last time you told me if we want to find out whether a file is cached or not
,
we can first do an atomic lookup, and if it succeeds, look up the first page
of the file, by doing an atomic (nonblocking) 1-byte do_generic_file_read.

So we add a path_walk() to the output.c to return a dentry of the file and
also
add do_generic_file_read() to do nonblocking read for the first inode of the
file.
The reason we choose generic_send_file() in output.c is the TUX control will
always
go here when TUX find a file is cache missed. So whenever a file is cached,
we
add an entry for this file in an array of tux_req_t . Whenever a file is not
in cached,
we delete its entry from this array. Then the backend server can use this
array to
get the front proxy  informed periodically  about which file currently is
cached in
which backend server. So the front proxy will forward.

But today we found we're wrong.  Actually we need to add our codes to a
callback
function instead of generic_send_file() . So we can query the file caching
status
periodically and update the file caching table in proxy.

Now I have several questions:
First, can we only use path_walk() plus do_generic_file_read to get the
correct caching status
of a user requested file?

Second , Do we need to implement  'atomic' GET_OBJECT by ourselves? Does
'atomic'
GET_OBJECT call you mentioned in your email  also consist of path_walk() and
do_generic_file_read()?

Third,  to which function of TUX should we add the  GET_OBJECT call? is the
event_loop in main.c an
ideal localtion for this since event_loop is called by Linux kernel
periodically?

Fourth, you say we should use TUX atom framework instead, what's the TUX
atom frameworkfor? how
can we use it to determine the file caching status?

Sorry to bother you again and again, we really want to say thanks for your
help.

Thank you.

Liang

> i'd rather suggest to introduce an 'atomic' GET_OBJECT call to determine
> whether an object is present or not. What would be the purpose of adding a
> path_walk() to the end of generic_send_file()? And keep in mind that it's
> all event driver, so you cannot just add blocking functions arbitrarily,
                 ^- driven
> the 'TUX atoms' framework should be used inste

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf
Of Ingo Molnar
Sent: Tuesday, April 02, 2002 7:39 AM
To: TUX Development Mailing List
Cc: Liang Yang
Subject: RE: How can TUX user module get notified when a page is removed
from cache?



On Tue, 2 Apr 2002, Liang Yang wrote:

> Here is the idea of our work. We need to query the caching status of
> files and notify the front end(a proxy) dynamically, so the proxy know
> in which backend server the user requested file is still cached and the
> proxy will only forward the user request to that machine which still
> keep the file in cache. If both the backend machines still cache the
> file, the proxy will select one randomly.  To simplify our model, now we
> don't need such kind of callback functions to be notified by Linux
> kernel which files is discarded, we will issue our request to query the
> file caching status in our user-space module.

ok, this scheme makes sense.

> We have some questions:
>
> First, if we call path_walk with atomic-lookup bit set and it returns a
> dentry, we know this file is 'cached'. But you say a file may be
> partially cached, so does path_walk still return a dentry when a file is
> partially cached.

yes. I'd suggest the following solution: extend the TUX module API with a
new call like TUX_ACTION_OBJECT_CACHED. This will be a transparent method
to tell whether the file is cached by this particular node or not.

on the kernel side i'd suggest for you to do an atomic lookup, and if it
succeeds, look up the first page of the file, by doing an atomic
(nonblocking) 1-byte do_generic_file_read. This is atomic and has low
overhead.

for 99% of the cases if the first byte of the file is cached then the
whole file is cached. You can still extend this mechanizm to look at
intermediate pages as well, if it becomes a practical issue anytime in the
future, your userspace module will not be affected by this.

[feel free to send me an email if you have trouble implementing this.]

> Second, can we use path_walk directly in our user-space modules and how
> to use it in user-space modules?

i'd suggest to provide the above TUX action, because this is a
functionality that is not sufficiently represented in the current Linux
API. So while it might be possible to look a file name up atomically from
userspace, it's not possible to do the 'is the first byte of the file
cached or not' kind of queries currently.

	Ingo



_______________________________________________
tux-list mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/tux-list