I have been looking at various notification and operation completion
processing mechanisms that we currently have in the kernel. (The
"operation" is typically I/O, but could be something else too).
This comes about as a result of observing similar patterns in async i/o
handling aspects in
We've just released version 1.3 of the Dynamic Probes facility. This has
2.4.0 and 2.2.18 support and some bug fixes, including Andi Kleen's
suggestions for fixing the races in handling of swapped out COW pages.
For more information on DProbes see the dprobes homepage at
Ok. Then we need an additional more or less generic object that is used
for
passing in a rw_kiovec file operation (and we really want that for many
kinds
of IO). I thould mostly be used for communicating to the high-level
driver.
/*
* the name is just plain stupid, but that shouldn't matter
Comments, suggestions, advise, feedback solicited !
If this seems like something that might (after some refinements) be a
useful abstraction to have, then I need some help in straightening out the
design. I am not very satisfied with it in its current form.
A Kernel Mechanism for Compound
Ben,
This indeed looks neat and simple !
I'd avoided touching the wait queue structure as I suspected that you might
already have something like this in place :-)
and was hoping that you'd see this posting and comment.
I agree entirely that it makes sense to have chaining of events built over
The waitqueue extension below is a minimalist approach for providing
kernel support for fully asynchronous io. The basic idea is that a
function pointer is added to the wait queue structure that is called
during wake_up on a wait queue head. (The patch below also includes
support for exclusive
Hi,
On Wed, Jan 31, 2001 at 07:28:01PM +0530, [EMAIL PROTECTED] wrote:
Do the following modifications to your wait queue extension sound
reasonable ?
1. Change add_wait_queue to add elements to the end of queue (fifo, by
default) and instead have an add_wait_queue_lifo() routine that
My first comment is that this looks very heavyweight indeed. Isn't it
just over-engineered?
Yes, I know it is, in its current form (sigh !).
But at the same time, I do not want to give up (not yet, at least) on
trying to arrive at something that can serve the objectives, and yet be
simple in
Here's a second pass attempt, based on Ben's wait queue extensions:
Does this sound any better ?
[This doesn't require any changes to the existing wait_queue_head based i/o
structures or to existing drivers, and the constructs mentioned come into
the picture only when compound events are
Hello Andi,
Thanks for taking the trouble to go through our code in such detail and
thinking through the race conditions in dp_vaddr_to_page, which I had sort
of shut my eyes to and postponed for while because it didn't seem very easy
to close all the loopholes in an elegant way. I need to
Andi,
Thanks. Then, I'll work it out in more detail and propose it on
linux-mm as you've suggested.
Maybe I should also try to think of another example where it might be
useful.
Anything that comes to mind ?
Regards
Suparna
Suparna Bhattacharya
Systems Software Group,
Version 2.0 of the Dynamic Probes facility is now available at
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
This release includes a new feature called "watchpoint probes" which
exploits hardware watchpoint capabilities of the underlying hardware
architecture to
(I have a complimentary hack that will dump the stacks of all the
rest of the threads as well (though its a good trick to get gdb to
interpret this). Available upon request.)
Hello Adam,
Could I take a look at your patch ?
Regards
Suparna
Suparna Bhattacharya
IBM Software Lab, India
Actually, I'm pretty sure you _never_ need to exportvg in order to have
it work on another system. That's one of the great things about AIX LVM,
because it means you can move a VG to another system after a hardware
problem, and not have any problems importing it (journaled fs also helps).
Because this is totally filesystem specific - why put extra knowledge
of filesystem internals into mount? I personally don't want it writing
into the ext2 or ext3 superblock. How can it possibly know what to do,
without embedding a lot of knowledge there? Yes, mount(8) can _read_
the UUID and
The vma list lock can nest with i_shared_lock, as per Kanoj Sarcar's
note on mem-mgmt locks (Documentation/vm/locking), and currently
vma list lock == mm-page_table_lock.
But there appears to be some inconsistency in the hierarchy of these
2 locks. (By vma list lock I mean
sct wrote:
Thanks for mentioning this. I didn't know about it earlier. I've been
going through the 4/00 kqueue patch on freebsd ...
Linus has already denounced them as massively over-engineered...
That shouldn't stop anyone from looking at them and learning, though.
There might be a
Hi,
On Thu, Feb 01, 2001 at 10:25:22AM +0530, [EMAIL PROTECTED] wrote:
We _do_ need the ability to stack completion events, but as far as the
kiobuf work goes, my current thoughts are to do that by stacking
lightweight "clone" kiobufs.
Would that work with stackable filesystems ?
Only if
Hi,
On Thu, Feb 01, 2001 at 01:28:33PM +0530, [EMAIL PROTECTED] wrote:
Here's a second pass attempt, based on Ben's wait queue extensions:
Does this sound any better ?
It's a mechanism, all right, but you haven't described what problems
it is trying to solve, and where it is likely to be
Hi,
On Fri, Feb 02, 2001 at 12:51:35PM +0100, Christoph Hellwig wrote:
If I have a page vector with a single offset/length pair, I can build
a new header with the same vector and modified offset/length to split
the vector in two without copying it.
You just say in the higher-level
Hi,
On Sun, Feb 04, 2001 at 06:54:58PM +0530, [EMAIL PROTECTED] wrote:
Can't we define a kiobuf structure as just this ? A combination of a
frag_list and a page_list ?
Then all code which needs to accept an arbitrary kiobuf needs to be
able to parse both --- ugh.
Making this a little
Hi,
On Mon, Feb 05, 2001 at 08:01:45PM +0530, [EMAIL PROTECTED] wrote:
It's the very essence of readahead that we wake up the earlier buffers
as soon as they become available, without waiting for the later ones
to complete, so we _need_ this multiple completion concept.
I can understand
Going through all the discussions once again and trying to look at this
from the point of view of just basic requirements for data structures and
mechanisms, that they imply.
1. Should have a data structure that represents a memory chain , which may
not be contiguous in physical memory, and
One question:
isn't it the case that the alternative to using synchronize_kernel()
is to protect the read side with explicit locks, which will themselves
suppress preemption? If so, why not just suppress preemption on the read
side in preemptible kernels, and thus gain the simpler
I have been looking at various notification and operation completion
processing mechanisms that we currently have in the kernel. (The
"operation" is typically I/O, but could be something else too).
This comes about as a result of observing similar patterns in async i/o
handling aspects in
We've just released version 1.3 of the Dynamic Probes facility. This has
2.4.0 and 2.2.18 support and some bug fixes, including Andi Kleen's
suggestions for fixing the races in handling of swapped out COW pages.
For more information on DProbes see the dprobes homepage at
>Ok. Then we need an additional more or less generic object that is used
for
>passing in a rw_kiovec file operation (and we really want that for many
kinds
>of IO). I thould mostly be used for communicating to the high-level
driver.
>
>/*
> * the name is just plain stupid, but that shouldn't
Comments, suggestions, advise, feedback solicited !
If this seems like something that might (after some refinements) be a
useful abstraction to have, then I need some help in straightening out the
design. I am not very satisfied with it in its current form.
A Kernel Mechanism for Compound
Ben,
This indeed looks neat and simple !
I'd avoided touching the wait queue structure as I suspected that you might
already have something like this in place :-)
and was hoping that you'd see this posting and comment.
I agree entirely that it makes sense to have chaining of events built over
Mathew,
Thanks for mentioning this. I didn't know about it earlier. I've been
going through the 4/00 kqueue patch on freebsd ...
Regards
Suparna
Suparna Bhattacharya
Systems Software Group, IBM Global Services, India
E-mail : [EMAIL PROTECTED]
Phone : 91-80-5267117, Extn :
>The waitqueue extension below is a minimalist approach for providing
>kernel support for fully asynchronous io. The basic idea is that a
>function pointer is added to the wait queue structure that is called
>during wake_up on a wait queue head. (The patch below also includes
>support for
>Hi,
>
>On Wed, Jan 31, 2001 at 07:28:01PM +0530, [EMAIL PROTECTED] wrote:
>>
>> Do the following modifications to your wait queue extension sound
>> reasonable ?
>>
>> 1. Change add_wait_queue to add elements to the end of queue (fifo, by
>> default) and instead have an add_wait_queue_lifo()
>My first comment is that this looks very heavyweight indeed. Isn't it
>just over-engineered?
Yes, I know it is, in its current form (sigh !).
But at the same time, I do not want to give up (not yet, at least) on
trying to arrive at something that can serve the objectives, and yet be
simple
Here's a second pass attempt, based on Ben's wait queue extensions:
Does this sound any better ?
[This doesn't require any changes to the existing wait_queue_head based i/o
structures or to existing drivers, and the constructs mentioned come into
the picture only when compound events are
sct wrote:
>> >
>> > Thanks for mentioning this. I didn't know about it earlier. I've been
>> > going through the 4/00 kqueue patch on freebsd ...
>>
>> Linus has already denounced them as massively over-engineered...
>
>That shouldn't stop anyone from looking at them and learning, though.
>Hi,
>
>On Thu, Feb 01, 2001 at 10:25:22AM +0530, [EMAIL PROTECTED] wrote:
>>
>> >We _do_ need the ability to stack completion events, but as far as the
>> >kiobuf work goes, my current thoughts are to do that by stacking
>> >lightweight "clone" kiobufs.
>>
>> Would that work with stackable
Version 2.0 of the Dynamic Probes facility is now available at
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
This release includes a new feature called "watchpoint probes" which
exploits hardware watchpoint capabilities of the underlying hardware
architecture to
>
>(I have a complimentary hack that will dump the stacks of all the
>rest of the threads as well (though its a good trick to get gdb to
>interpret this). Available upon request.)
>
Hello Adam,
Could I take a look at your patch ?
Regards
Suparna
Suparna Bhattacharya
IBM Software Lab,
>Actually, I'm pretty sure you _never_ need to exportvg in order to have
>it work on another system. That's one of the great things about AIX LVM,
>because it means you can move a VG to another system after a hardware
>problem, and not have any problems importing it (journaled fs also helps).
>Because this is totally filesystem specific - why put extra knowledge
>of filesystem internals into mount? I personally don't want it writing
>into the ext2 or ext3 superblock. How can it possibly know what to do,
>without embedding a lot of knowledge there? Yes, mount(8) can _read_
>the
Hello Andi,
Thanks for taking the trouble to go through our code in such detail and
thinking through the race conditions in dp_vaddr_to_page, which I had sort
of shut my eyes to and postponed for while because it didn't seem very easy
to close all the loopholes in an elegant way. I need to
Andi,
Thanks. Then, I'll work it out in more detail and propose it on
linux-mm as you've suggested.
Maybe I should also try to think of another example where it might be
useful.
Anything that comes to mind ?
Regards
Suparna
Suparna Bhattacharya
Systems Software Group,
The vma list lock can nest with i_shared_lock, as per Kanoj Sarcar's
note on mem-mgmt locks (Documentation/vm/locking), and currently
vma list lock == mm->page_table_lock.
But there appears to be some inconsistency in the hierarchy of these
2 locks. (By vma list lock I mean
>Hi,
>
>On Thu, Feb 01, 2001 at 01:28:33PM +0530, [EMAIL PROTECTED] wrote:
>>
>> Here's a second pass attempt, based on Ben's wait queue extensions:
> Does this sound any better ?
>
>It's a mechanism, all right, but you haven't described what problems
>it is trying to solve, and where it is
>Hi,
>
>On Fri, Feb 02, 2001 at 12:51:35PM +0100, Christoph Hellwig wrote:
>> >
>> > If I have a page vector with a single offset/length pair, I can build
>> > a new header with the same vector and modified offset/length to split
>> > the vector in two without copying it.
>>
>> You just say in
>Hi,
>
>On Sun, Feb 04, 2001 at 06:54:58PM +0530, [EMAIL PROTECTED] wrote:
>>
>> Can't we define a kiobuf structure as just this ? A combination of a
>> frag_list and a page_list ?
>
>Then all code which needs to accept an arbitrary kiobuf needs to be
>able to parse both --- ugh.
>
Making
>Hi,
>
>On Mon, Feb 05, 2001 at 08:01:45PM +0530, [EMAIL PROTECTED] wrote:
>>
>> >It's the very essence of readahead that we wake up the earlier buffers
>> >as soon as they become available, without waiting for the later ones
>> >to complete, so we _need_ this multiple completion concept.
>>
>>
Going through all the discussions once again and trying to look at this
from the point of view of just basic requirements for data structures and
mechanisms, that they imply.
1. Should have a data structure that represents a memory chain , which may
not be contiguous in physical memory, and
>One question:
>isn't it the case that the alternative to using synchronize_kernel()
>is to protect the read side with explicit locks, which will themselves
>suppress preemption? If so, why not just suppress preemption on the read
>side in preemptible kernels, and thus gain the simpler
49 matches
Mail list logo
