>> But this won't happen if next
>>started as 0 and we didn't update it. I don't know if retrying is the
>>intended behaviour or if we care that the start == 0 case doesn't do it.
>
>
> Good point. Let's make it explicit?
Looks great. I briefly had visions of some bitfield to pack the three
But this won't happen if next
started as 0 and we didn't update it. I don't know if retrying is the
intended behaviour or if we care that the start == 0 case doesn't do it.
Good point. Let's make it explicit?
Looks great. I briefly had visions of some bitfield to pack the three
boolean
Zach Brown <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>
> > I'd be inclined to hold off on the macro until we actually get the
> > open-coded stuff right.. Sometimes the page lookup loops take an end+1
> > argument and sometimes they take an inclusive `end'. I think. That might
> >
Andrew Morton wrote:
> I'd be inclined to hold off on the macro until we actually get the
> open-coded stuff right.. Sometimes the page lookup loops take an end+1
> argument and sometimes they take an inclusive `end'. I think. That might
> make it a bit messy.
>
> How's this look?
Looks
Andrew Morton wrote:
I'd be inclined to hold off on the macro until we actually get the
open-coded stuff right.. Sometimes the page lookup loops take an end+1
argument and sometimes they take an inclusive `end'. I think. That might
make it a bit messy.
How's this look?
Looks good. It
Zach Brown [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
I'd be inclined to hold off on the macro until we actually get the
open-coded stuff right.. Sometimes the page lookup loops take an end+1
argument and sometimes they take an inclusive `end'. I think. That might
make it a bit
Zach Brown <[EMAIL PROTECTED]> wrote:
>
> > I'll make that change and plop the patch into -mm, but we need to think
> > about the infinite-loop problem..
>
> I can try hacking together that macro and auditing pagevec_lookup()
> callers..
I'd be inclined to hold off on the macro until we
Andrew Morton wrote:
> Note that the same optimisation should be made in the call to
> unmap_mapping_range() in generic_file_direct_IO(). Currently we try and
> unmap the whole file, even if we're only writing a single byte. Given that
> you're now calculating iov_length() in there we might as
Zach Brown <[EMAIL PROTECTED]> wrote:
>
> After a direct IO write only invalidate the pages that the write intersected.
> invalidate_inode_pages2_range(mapping, pgoff start, pgoff end) is added and
> called from generic_file_direct_IO(). This doesn't break some subtle
> agreement
> with some
Zach Brown [EMAIL PROTECTED] wrote:
After a direct IO write only invalidate the pages that the write intersected.
invalidate_inode_pages2_range(mapping, pgoff start, pgoff end) is added and
called from generic_file_direct_IO(). This doesn't break some subtle
agreement
with some other part
Andrew Morton wrote:
Note that the same optimisation should be made in the call to
unmap_mapping_range() in generic_file_direct_IO(). Currently we try and
unmap the whole file, even if we're only writing a single byte. Given that
you're now calculating iov_length() in there we might as well
Zach Brown [EMAIL PROTECTED] wrote:
I'll make that change and plop the patch into -mm, but we need to think
about the infinite-loop problem..
I can try hacking together that macro and auditing pagevec_lookup()
callers..
I'd be inclined to hold off on the macro until we actually get
After a direct IO write only invalidate the pages that the write intersected.
invalidate_inode_pages2_range(mapping, pgoff start, pgoff end) is added and
called from generic_file_direct_IO(). This doesn't break some subtle agreement
with some other part of the code, does it?
While we're in
After a direct IO write only invalidate the pages that the write intersected.
invalidate_inode_pages2_range(mapping, pgoff start, pgoff end) is added and
called from generic_file_direct_IO(). This doesn't break some subtle agreement
with some other part of the code, does it?
While we're in
14 matches
Mail list logo
