headers
Bryan Henderson | 1 Apr 2005 02:06
Picon
Favicon

Re: Address space operations questions

>It reflects the fact that the page lock can be held for a variety of
>reasons, some of which require you to kick the filesystem and some which
>don't.

So then what I don't understand is why you would make a call that tells 
you someone is trying to hold the page lock?  Why not a call that tells 
you something meaningful like, "someone is trying to read this page"?  Or 
"someone is waiting for this page to get clean?"

>I introduced the sync_page() call in 2.4.x partly in order to get rid of
>all those pathetic hard-coded calls to "run_task_queue(&tq_disk)"

That was pathetic all right, and sync_page() would be a clear improvement 
if it just replaced those modularity-busting I/O scheduling calls.  But 
did it?  Were there run_task_queue's every time the kernel waited for page 
status to change?  I thought they were in more eclectic places.

>the NFS client itself had to defer actually
>putting reads on the wire until someone requested the lock

But really, you mean the client had to defer putting reads on the wire 
until someone was ready to use the data.  That suggests a call to 
->sync_page in file read or page fault code rather than deep in page 
management.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Apr 2005 02:13

Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O

Trond Myklebust <trondmy <at> trondhjem.org> wrote:
>
>  on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust:
>  > > Or have I misunderstood the intent?  Some /* comments */ would be appropriate..
>  > 
>  > Will do.
> 
>  OK. Plenty of comments added that will hopefully clarify what is going
>  on and how to use the API. Also some cleanups of the code.

Ah, so that's what it does ;)

I guess once we have a caller in-tree we could merge this.  I wonder if
there's other existing code which should be converted to iosems.

You chose to not use the aio kernel threads?

Does iosem_lock_and_schedule_function() need locking?  It nonatomically
alters *lk_state.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 55 comments |
headers
Trond Myklebust | 1 Apr 2005 03:22
Picon
Picon

Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O

to den 31.03.2005 Klokka 16:13 (-0800) skreiv Andrew Morton:
> Trond Myklebust <trondmy <at> trondhjem.org> wrote:
> >
> >  on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust:
> >  > > Or have I misunderstood the intent?  Some /* comments */ would be appropriate..
> >  > 
> >  > Will do.
> > 
> >  OK. Plenty of comments added that will hopefully clarify what is going
> >  on and how to use the API. Also some cleanups of the code.
> 
> Ah, so that's what it does ;)
> 
> I guess once we have a caller in-tree we could merge this.  I wonder if
> there's other existing code which should be converted to iosems.

I can put it into the NFS client stream which feeds into the -mm kernel.
That will enable me to queue up the NFSv4 patches that depend on it
too...

> You chose to not use the aio kernel threads?

I thought I'd do that in a separate patch since the aio workqueue is
currently statically defined in aio.c.

> Does iosem_lock_and_schedule_function() need locking?  It nonatomically
> alters *lk_state.

iosem_lock_and_schedule_function() will always be called with the
iosem->wait.lock held, since it is a waitqueue notification function.
(Continue reading)

Permalink | Reply | 53 comments |
headers
Suparna Bhattacharya | 1 Apr 2005 16:12
Picon

Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O

On Thu, Mar 31, 2005 at 08:22:17PM -0500, Trond Myklebust wrote:
> to den 31.03.2005 Klokka 16:13 (-0800) skreiv Andrew Morton:
> > Trond Myklebust <trondmy <at> trondhjem.org> wrote:
> > >
> > >  on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust:
> > >  > > Or have I misunderstood the intent?  Some /* comments */ would be appropriate..
> > >  > 
> > >  > Will do.
> > > 
> > >  OK. Plenty of comments added that will hopefully clarify what is going
> > >  on and how to use the API. Also some cleanups of the code.
> > 
> > Ah, so that's what it does ;)
> > 
> > I guess once we have a caller in-tree we could merge this.  I wonder if
> > there's other existing code which should be converted to iosems.
> 
> I can put it into the NFS client stream which feeds into the -mm kernel.
> That will enable me to queue up the NFSv4 patches that depend on it
> too...
> 
> > You chose to not use the aio kernel threads?
> 
> I thought I'd do that in a separate patch since the aio workqueue is
> currently statically defined in aio.c.

I'll take a look at the patch over the weekend. I had a patch
for aio semaphores a long while back, but I need to spend some time
to understand how different this is.
(Continue reading)

Permalink | Reply | 50 comments |
headers
Marek Szyprowski | 3 Apr 2005 21:12
Picon

Re: ASFS filesystem driver, kernel 2.6.xx

Hello maximilian

On 28.03.05, you wrote:

>> Patch for 2.6.xx kernel tree is available on
>>
>>
http://home.elka.pw.edu.pl/~mszyprow/programy/asfs/asfs-1.0b9_patch_2.6.10.diff.gz

> a bit hard to read while you are offline on easter vacation.
> although svenl pointed out that i should know that patch from
> the debian kernel. /me bad.

> could you send it to akpm for inclusion?

OK. I did it. I hope that akpm <at> osdl.org is right e-mail address.

Regards
--

-- 
Marek Szyprowski .. GG:2309080 .. mailto:marek <at> amiga.pl ..
..... happy MorphOS, AmigaOS and Debian/Linux user .......

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Joel Becker | 3 Apr 2005 21:57
Picon
Favicon

[PATCH] configfs, a filesystem for userspace-driven kernel object configuration

Folks,
	I humbly submit configfs.  With configfs, a configfs
config_item is created via an explicit userspace operation: mkdir(2).
It is destroyed via rmdir(2).  The attributes appear at mkdir(2) time,
and can be read or modified via read(2) and write(2).  readdir(3)
queries the list of items and/or attributes.
	The lifetime of the filesystem representation is completely
driven by userspace.  The lifetime of the objects themselves are managed
by a kref, but at rmdir(2) time they disappear from the filesystem.
	configfs is not intended to replace sysfs or procfs, merely to
coexist with them.
	An interface in /proc where the API is: 

	# echo "create foo 1 3 0x00013" > /proc/mythingy

or an ioctl(2) interface where the API is:

	struct mythingy_create {
		char *name;
		int index;
		int count;
		unsigned long address;
	}

	do_create {
		mythingy_create = {"foo", 1, 3, 0x0013};
		return ioctl(fd, MYTHINGY_CREATE, &mythingy_create);
	}

becomes this in configfs:
(Continue reading)

Permalink | Reply | 10 comments |
headers
Joel Becker | 3 Apr 2005 22:40
Picon
Favicon

Re: [PATCH] configfs, a filesystem for userspace-driven kernel object configuration

On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote:
> 	I humbly submit configfs.  With configfs, a configfs
> ...
> 	Patch is against 2.6.12-rc1-bk3.

	Updated for bk5 and the new backing_dev capabilites mask:

http://oss.oracle.com/~jlbec/files/configfs/2.6.12-rc1-bk5/configfs-2.6.12-rc1-bk5-1.patch

Joel

--

-- 

"Against stupidity the Gods themselves contend in vain."
	- Freidrich von Schiller

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: joel.becker <at> oracle.com
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Suparna Bhattacharya | 4 Apr 2005 07:20
Picon

Re: AIO and vectored I/O support for cifs


cc'ing linux-aio, for the AIO part of the discussion. You might be able
to find some of your answers in the archives.

On Fri, Mar 25, 2005 at 03:26:23PM -0600, Steve French wrote:
> Christoph,
> I had time to add the generic vectored i/o and async i/o calls to cifs 
> that you had suggested last month.  They are within the ifdef for the 
> CIFS_EXPERIMENTAL config option for the time being.   I would like to do 
> more testing of these though - are there any tests (even primitive ones) 
> for readv/writev and async i/o?
> 
> Is there an easy way measuring the performance benefit of these (vs. the 
> fallback routines in fs/read_write.c) - since presumably async and 
> vectored i/o never kick in on a standard copy command such as cp or dd 
> and require a modified application that is vector i/o aware or async i/o 
> aware.

there are several tests for AIO - I tend to use Chris Mason's aio-stress
which can be used to compare performance in terms of throughput for
streaming reads/writes for different variations of options.

(the following page isn't exactly up-to-date, but should still give
you some pointers: lse.sf.net/io/aio.html)

> 
> You had mentioned do_sync_read - is there a reason to change the current 
> call to generic_file_read in the cifs read entry point to do_sync_read.  
> Some filesystems which export aio routines still call generic_file_read 
> and others call do_sync_read and it was not obvious to me what that
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steve French | 4 Apr 2005 07:43
Picon

Re: AIO and vectored I/O support for cifs

Suparna Bhattacharya wrote:

>cc'ing linux-aio, for the AIO part of the discussion. You might be able
>to find some of your answers in the archives.
>
>there are several tests for AIO - I tend to use Chris Mason's aio-stress
>which can be used to compare performance in terms of throughput for
>streaming reads/writes for different variations of options.
>
>(the following page isn't exactly up-to-date, but should still give
>you some pointers: lse.sf.net/io/aio.html)
>  
>
Thanks - those were lists that I was not aware of.

>>You had mentioned do_sync_read - is there a reason to change the current 
>>call to generic_file_read in the cifs read entry point to do_sync_read.  
>>Some filesystems which export aio routines still call generic_file_read 
>>and others call do_sync_read and it was not obvious to me what that 
>>would change.
>>    
>>
>
>I think you could keep it the way it is - generic_file_read will take care
>of things. But maybe I should comment only after I see your patch. Are
>you planning to post it some time ?
>
>Regards
>Suparna
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Suparna Bhattacharya | 4 Apr 2005 17:52
Picon

Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O

[cc'ing linux-aio]

The way I did this for semaphores was to modify the down routines to accept
an explicit wait queue entry parameter, so the caller could set it up to
be a synchronous waiter or a callback as appropriate. Of course, in the
AIO case, the callback was setup to restart the iocb operation to continue
rest of its processing, which was when it acquired the lock. So, the
callback in itself didn't need to remember the lock. The only grey area
that I didn't resolve to satisfaction

And oh yes, even though this was a really small change, having to
update and verify those umpteen different arch specific pieces was not
entirely an exciting prospect - I got as far as x86, x86_64 and ppc64
... but stopped after that. It so happened that i_sem contention
didn't show up as a major latency issue even without async semaphores
in the kinds of workloads we were working with then.

Your approach looks reasonable and simple enough. It'd be useful if I
could visualize the caller side of things as in the NFS client stream
as you mention - do you plan to post that soon ? 
I'm tempted to think about the possibility of using your iosems
with retry-based AIO.

Regards
Suparna

On Fri, Apr 01, 2005 at 07:42:25PM +0530, Suparna Bhattacharya wrote:
> On Thu, Mar 31, 2005 at 08:22:17PM -0500, Trond Myklebust wrote:
> > to den 31.03.2005 Klokka 16:13 (-0800) skreiv Andrew Morton:
> > > Trond Myklebust <trondmy <at> trondhjem.org> wrote:
(Continue reading)

Permalink | Reply | 46 comments |

Gmane