Hi Andrew,
On Sun, 6 Feb 2005, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > On Thu, 3 Feb 2005, Andrew Morton wrote:
> > > I did a patch which switched loop to use the file_operations.read/write
> > > about a year ago. Forget what happened to it. It always seemed the
Hi Andrew,
On Sun, 6 Feb 2005, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
On Thu, 3 Feb 2005, Andrew Morton wrote:
I did a patch which switched loop to use the file_operations.read/write
about a year ago. Forget what happened to it. It always seemed the right
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
>
> On Thu, 3 Feb 2005, Andrew Morton wrote:
> > I did a patch which switched loop to use the file_operations.read/write
> > about a year ago. Forget what happened to it. It always seemed the right
> > thing to do..
>
> How did you implement the
On Thu, 3 Feb 2005, Andrew Morton wrote:
> I did a patch which switched loop to use the file_operations.read/write
> about a year ago. Forget what happened to it. It always seemed the right
> thing to do..
How did you implement the write? At the moment the loop driver gets hold
of both source
On Thu, 3 Feb 2005, Andrew Morton wrote:
I did a patch which switched loop to use the file_operations.read/write
about a year ago. Forget what happened to it. It always seemed the right
thing to do..
How did you implement the write? At the moment the loop driver gets hold
of both source
Anton Altaparmakov [EMAIL PROTECTED] wrote:
On Thu, 3 Feb 2005, Andrew Morton wrote:
I did a patch which switched loop to use the file_operations.read/write
about a year ago. Forget what happened to it. It always seemed the right
thing to do..
How did you implement the write?
It was
On Fri, 4 Feb 2005, Anton Altaparmakov wrote:
> On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
> >
> > I think the point is that we can't have a "handler for writes," because
> > the writes are being done by simple CPU Store instructions in a user
> > program. The handler we're
On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
> >> > > And for the vmscan->writepage() side of things I wonder if it would
> be
> >> > > possible to overload the mapping's ->nopage handler. If the target
> page
> >> > > lies in a hole, go off and allocate all the necessary pagecache
On Fri, 4 Feb 2005, Anton Altaparmakov wrote:
On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
I think the point is that we can't have a handler for writes, because
the writes are being done by simple CPU Store instructions in a user
program. The handler we're talking about
On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
And for the vmscan-writepage() side of things I wonder if it would
be
possible to overload the mapping's -nopage handler. If the target
page
lies in a hole, go off and allocate all the necessary pagecache
pages, zero
>I did a patch which switched loop to use the file_operations.read/write
>about a year ago. Forget what happened to it. It always seemed the
right
>thing to do..
This is unquestionably the right thing to do (at least compared to what we
have now). The loop device driver has no business
>> > > And for the vmscan->writepage() side of things I wonder if it would
be
>> > > possible to overload the mapping's ->nopage handler. If the target
page
>> > > lies in a hole, go off and allocate all the necessary pagecache
pages, zero
>> > > them, mark them dirty?
>> >
>> > I guess it
On Thu, 2005-02-03 at 02:47 -0800, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
> > > Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Below is a patch which adds a function
> > > >
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
> > Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > >
> > > Below is a patch which adds a function
> > > mm/filemap.c::find_or_create_pages(), locks a range of pages. Please
> > > see
>
On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> >
> > Below is a patch which adds a function
> > mm/filemap.c::find_or_create_pages(), locks a range of pages. Please see
> > the function description in the patch for details.
>
> This
On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
Below is a patch which adds a function
mm/filemap.c::find_or_create_pages(), locks a range of pages. Please see
the function description in the patch for details.
This isn't very
Anton Altaparmakov [EMAIL PROTECTED] wrote:
On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
Below is a patch which adds a function
mm/filemap.c::find_or_create_pages(), locks a range of pages. Please
see
the function
On Thu, 2005-02-03 at 02:47 -0800, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
On Wed, 2005-02-02 at 14:34 -0800, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
Below is a patch which adds a function
mm/filemap.c::find_or_create_pages(),
And for the vmscan-writepage() side of things I wonder if it would
be
possible to overload the mapping's -nopage handler. If the target
page
lies in a hole, go off and allocate all the necessary pagecache
pages, zero
them, mark them dirty?
I guess it would be possible but
I did a patch which switched loop to use the file_operations.read/write
about a year ago. Forget what happened to it. It always seemed the
right
thing to do..
This is unquestionably the right thing to do (at least compared to what we
have now). The loop device driver has no business assuming
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
>
> Below is a patch which adds a function
> mm/filemap.c::find_or_create_pages(), locks a range of pages. Please see
> the function description in the patch for details.
This isn't very nice, is it, really? Kind of a square peg in a round hole.
Hi Matthew,
On Wed, 2005-02-02 at 15:43 +, Matthew Wilcox wrote:
> On Wed, Feb 02, 2005 at 03:12:50PM +, Anton Altaparmakov wrote:
>
> I think the below loop would be clearer as a for loop ...
>
> err = 0;
> for (nr = 0; nr < nr_pages; nr++, start++) {
> if
On Wed, Feb 02, 2005 at 03:12:50PM +, Anton Altaparmakov wrote:
I think the below loop would be clearer as a for loop ...
err = 0;
for (nr = 0; nr < nr_pages; nr++, start++) {
if (start == lp_idx) {
pages[nr] = locked_page;
Hi,
On Thu, 27 Jan 2005, Andrew Morton wrote:
> Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > What would you propose can I do to perform the required zeroing in a
> > deadlock safe manner whilst also ensuring that it cannot happen that a
> > concurrent ->readpage() will cause me to miss a
Hi,
On Thu, 27 Jan 2005, Andrew Morton wrote:
Anton Altaparmakov [EMAIL PROTECTED] wrote:
What would you propose can I do to perform the required zeroing in a
deadlock safe manner whilst also ensuring that it cannot happen that a
concurrent -readpage() will cause me to miss a page and thus
On Wed, Feb 02, 2005 at 03:12:50PM +, Anton Altaparmakov wrote:
I think the below loop would be clearer as a for loop ...
err = 0;
for (nr = 0; nr nr_pages; nr++, start++) {
if (start == lp_idx) {
pages[nr] = locked_page;
Hi Matthew,
On Wed, 2005-02-02 at 15:43 +, Matthew Wilcox wrote:
On Wed, Feb 02, 2005 at 03:12:50PM +, Anton Altaparmakov wrote:
I think the below loop would be clearer as a for loop ...
err = 0;
for (nr = 0; nr nr_pages; nr++, start++) {
if (start ==
Anton Altaparmakov [EMAIL PROTECTED] wrote:
Below is a patch which adds a function
mm/filemap.c::find_or_create_pages(), locks a range of pages. Please see
the function description in the patch for details.
This isn't very nice, is it, really? Kind of a square peg in a round hole.
If
28 matches
Mail list logo
