Denis Vlasenko wrote:
On Friday 05 January 2007 17:20, Bill Davidsen wrote:
Denis Vlasenko wrote:
But O_DIRECT is _not_ about cache. At least I think it was not about
cache initially, it was more about DMAing data directly from/to
application address space to/from disks, saving
Denis Vlasenko wrote:
On Friday 05 January 2007 17:20, Bill Davidsen wrote:
Denis Vlasenko wrote:
But O_DIRECT is _not_ about cache. At least I think it was not about
cache initially, it was more about DMAing data directly from/to
application address space to/from disks, saving
On Friday 05 January 2007 17:20, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > But O_DIRECT is _not_ about cache. At least I think it was not about
> > cache initially, it was more about DMAing data directly from/to
> > application address space to/from disks, saving memcpy's and double
> >
Denis Vlasenko wrote:
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
Hugh Dickins wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache
used by other applications. An application which writes a large quantity
of data will have less impact on other
On 05/01/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
On 04/01/07, Hua Zhong <[EMAIL PROTECTED]> wrote:
> > I see that as a good argument _not_ to allow O_DIRECT on
> > tmpfs, which inevitably impacts cache, even if O_DIRECT were
> > requested.
> >
> > But I'd also expect any app requesting
On 04/01/07, Hua Zhong <[EMAIL PROTECTED]> wrote:
> I see that as a good argument _not_ to allow O_DIRECT on
> tmpfs, which inevitably impacts cache, even if O_DIRECT were
> requested.
>
> But I'd also expect any app requesting O_DIRECT in that way,
> as a caring citizen, to fall back to going
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Hua Zhong wrote:
So I'd argue that it makes more sense to support O_DIRECT
on tmpfs as the memory IS the backing store.
A few more voices in favour and I'll be persuaded. Perhaps I'm
out of date: when O_DIRECT came in, just a few filesystems
Hugh Dickins wrote:
> On Thu, 4 Jan 2007, Michael Tokarev wrote:
>> I wonder why open() with O_DIRECT (for example) bit set is
>> disallowed on a tmpfs (again, for example) filesystem,
>> returning EINVAL.
[]
> p.s. You said "O_DIRECT (for example)" - what other open
> flag do you think tmpfs
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Michael Tokarev wrote:
I wonder why open() with O_DIRECT (for example) bit set is
disallowed on a tmpfs (again, for example) filesystem,
returning EINVAL.
[]
p.s. You said O_DIRECT (for example) - what other open
flag do you think tmpfs should support
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Hua Zhong wrote:
So I'd argue that it makes more sense to support O_DIRECT
on tmpfs as the memory IS the backing store.
A few more voices in favour and I'll be persuaded. Perhaps I'm
out of date: when O_DIRECT came in, just a few filesystems
On 04/01/07, Hua Zhong [EMAIL PROTECTED] wrote:
I see that as a good argument _not_ to allow O_DIRECT on
tmpfs, which inevitably impacts cache, even if O_DIRECT were
requested.
But I'd also expect any app requesting O_DIRECT in that way,
as a caring citizen, to fall back to going without
On 05/01/07, Jesper Juhl [EMAIL PROTECTED] wrote:
On 04/01/07, Hua Zhong [EMAIL PROTECTED] wrote:
I see that as a good argument _not_ to allow O_DIRECT on
tmpfs, which inevitably impacts cache, even if O_DIRECT were
requested.
But I'd also expect any app requesting O_DIRECT in that
Denis Vlasenko wrote:
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
Hugh Dickins wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache
used by other applications. An application which writes a large quantity
of data will have less impact on other
On Friday 05 January 2007 17:20, Bill Davidsen wrote:
Denis Vlasenko wrote:
But O_DIRECT is _not_ about cache. At least I think it was not about
cache initially, it was more about DMAing data directly from/to
application address space to/from disks, saving memcpy's and double
allocations.
Hugh Dickins wrote on Thursday, January 04, 2007 11:14 AM
> On Thu, 4 Jan 2007, Hua Zhong wrote:
> > So I'd argue that it makes more sense to support O_DIRECT
> > on tmpfs as the memory IS the backing store.
>
> A few more voices in favour and I'll be persuaded. Perhaps I'm
> out of date: when
Denis Vlasenko wrote:
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
Hugh Dickins wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache
used by other applications. An application which writes a large quantity
of data will have less impact on other applications
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
> Hugh Dickins wrote:
> In many cases the use of O_DIRECT is purely to avoid impact on cache
> used by other applications. An application which writes a large quantity
> of data will have less impact on other applications by using O_DIRECT,
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Hua Zhong wrote:
So I'd argue that it makes more sense to support O_DIRECT
on tmpfs as the memory IS the backing store.
A few more voices in favour and I'll be persuaded.
I see no reason to restrict it as is currently done.
Policy belongs in
On Thu, 4 Jan 2007, Hua Zhong wrote:
>
> So I'd argue that it makes more sense to support O_DIRECT
> on tmpfs as the memory IS the backing store.
A few more voices in favour and I'll be persuaded. Perhaps I'm
out of date: when O_DIRECT came in, just a few filesystems supported
it, and it was
> I see that as a good argument _not_ to allow O_DIRECT on
> tmpfs, which inevitably impacts cache, even if O_DIRECT were
> requested.
>
> But I'd also expect any app requesting O_DIRECT in that way,
> as a caring citizen, to fall back to going without O_DIRECT
> when it's not supported.
Peter Staubach wrote:
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Bill Davidsen wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache
used by
other applications. An application which writes a large quantity of
data will
have less impact on other applications by using
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Bill Davidsen wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache used by
other applications. An application which writes a large quantity of data will
have less impact on other applications by using O_DIRECT, assuming that the
On Thu, 4 Jan 2007, Bill Davidsen wrote:
>
> In many cases the use of O_DIRECT is purely to avoid impact on cache used by
> other applications. An application which writes a large quantity of data will
> have less impact on other applications by using O_DIRECT, assuming that the
> data will not
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Michael Tokarev wrote:
I wonder why open() with O_DIRECT (for example) bit set is
disallowed on a tmpfs (again, for example) filesystem,
returning EINVAL.
Because it would be (a very small amount of) work and bloat to
support O_DIRECT on tmpfs; because
Michael Tokarev <[EMAIL PROTECTED]> wrote:
> I wonder why open() with O_DIRECT (for example) bit set is
> disallowed on a tmpfs (again, for example) filesystem,
> returning EINVAL.
>
> Yes, the question may seems strange a bit, because of two
> somewhat conflicting reasons. First, there's no
On Thu, 4 Jan 2007, Michael Tokarev wrote:
> I wonder why open() with O_DIRECT (for example) bit set is
> disallowed on a tmpfs (again, for example) filesystem,
> returning EINVAL.
Because it would be (a very small amount of) work and bloat to
support O_DIRECT on tmpfs; because that work didn't
On Thu, 4 Jan 2007, Michael Tokarev wrote:
I wonder why open() with O_DIRECT (for example) bit set is
disallowed on a tmpfs (again, for example) filesystem,
returning EINVAL.
Because it would be (a very small amount of) work and bloat to
support O_DIRECT on tmpfs; because that work didn't seem
Michael Tokarev [EMAIL PROTECTED] wrote:
I wonder why open() with O_DIRECT (for example) bit set is
disallowed on a tmpfs (again, for example) filesystem,
returning EINVAL.
Yes, the question may seems strange a bit, because of two
somewhat conflicting reasons. First, there's no reason to
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Michael Tokarev wrote:
I wonder why open() with O_DIRECT (for example) bit set is
disallowed on a tmpfs (again, for example) filesystem,
returning EINVAL.
Because it would be (a very small amount of) work and bloat to
support O_DIRECT on tmpfs; because
On Thu, 4 Jan 2007, Bill Davidsen wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache used by
other applications. An application which writes a large quantity of data will
have less impact on other applications by using O_DIRECT, assuming that the
data will not be
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Bill Davidsen wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache used by
other applications. An application which writes a large quantity of data will
have less impact on other applications by using O_DIRECT, assuming that the
Peter Staubach wrote:
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Bill Davidsen wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache
used by
other applications. An application which writes a large quantity of
data will
have less impact on other applications by using
I see that as a good argument _not_ to allow O_DIRECT on
tmpfs, which inevitably impacts cache, even if O_DIRECT were
requested.
But I'd also expect any app requesting O_DIRECT in that way,
as a caring citizen, to fall back to going without O_DIRECT
when it's not supported.
According
On Thu, 4 Jan 2007, Hua Zhong wrote:
So I'd argue that it makes more sense to support O_DIRECT
on tmpfs as the memory IS the backing store.
A few more voices in favour and I'll be persuaded. Perhaps I'm
out of date: when O_DIRECT came in, just a few filesystems supported
it, and it was
Hugh Dickins wrote:
On Thu, 4 Jan 2007, Hua Zhong wrote:
So I'd argue that it makes more sense to support O_DIRECT
on tmpfs as the memory IS the backing store.
A few more voices in favour and I'll be persuaded.
I see no reason to restrict it as is currently done.
Policy belongs in
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
Hugh Dickins wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache
used by other applications. An application which writes a large quantity
of data will have less impact on other applications by using O_DIRECT,
Denis Vlasenko wrote:
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
Hugh Dickins wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache
used by other applications. An application which writes a large quantity
of data will have less impact on other applications
Hugh Dickins wrote on Thursday, January 04, 2007 11:14 AM
On Thu, 4 Jan 2007, Hua Zhong wrote:
So I'd argue that it makes more sense to support O_DIRECT
on tmpfs as the memory IS the backing store.
A few more voices in favour and I'll be persuaded. Perhaps I'm
out of date: when O_DIRECT
38 matches
Mail list logo
