linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Re: posix_fadvise
       [not found]   ` <m3snwofzo4.fsf@localhost.localnet>
@ 2000-04-14 20:45     ` Jamie Lokier
  2000-04-14 20:56       ` posix_fadvise Ulrich Drepper
  0 siblings, 1 reply; 6+ messages in thread
From: Jamie Lokier @ 2000-04-14 20:45 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: VGER kernel list, linux-mm, Chuck Lever

Ulrich Drepper wrote:
> > What does POSIX_FADV_DONTNEED mean?  MADV_DONTNEED has at least three
> > incompatible meanings between different unix systems...
> 
> Their definition is:
> 
>   Specifies that the applicatione xpects that it will not access the
>   specified data in the near future.

Ok.  You should be aware that the present Linux implementation of
MADV_DONTNEED is "nukes dirty data".  Do you have a POSIX standard that
says POSIX MADV_DONTNEED should be similar to POSIX_FADV_DONTNEED?

There was some discussion on linux-mm about renaming this behaviour to
MADV_WONTNEED or MADV_DISCARD to avoid ambiguity.  Some other OSes
implement MADV_DONTNEED by discarding data, but there are at least two
other semantics around including one like POSIX_FADV_DONTNEED.

enjoy,
-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: posix_fadvise
  2000-04-14 20:45     ` posix_fadvise Jamie Lokier
@ 2000-04-14 20:56       ` Ulrich Drepper
  2000-04-14 21:24         ` posix_fadvise Jamie Lokier
  0 siblings, 1 reply; 6+ messages in thread
From: Ulrich Drepper @ 2000-04-14 20:56 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: VGER kernel list, linux-mm, Chuck Lever

Jamie Lokier <lk@tantalophile.demon.co.uk> writes:

> Ok.  You should be aware that the present Linux implementation of
> MADV_DONTNEED is "nukes dirty data".  Do you have a POSIX standard that
> says POSIX MADV_DONTNEED should be similar to POSIX_FADV_DONTNEED?

Yes.  But this shouldn't be a problem.  Nobody says that nuking isn't OK.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: posix_fadvise
  2000-04-14 20:56       ` posix_fadvise Ulrich Drepper
@ 2000-04-14 21:24         ` Jamie Lokier
  2000-04-14 21:35           ` posix_fadvise Ulrich Drepper
  0 siblings, 1 reply; 6+ messages in thread
From: Jamie Lokier @ 2000-04-14 21:24 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: VGER kernel list, linux-mm, Chuck Lever

Ulrich Drepper wrote:
> Jamie Lokier <lk@tantalophile.demon.co.uk> writes:
> 
> > Ok.  You should be aware that the present Linux implementation of
> > MADV_DONTNEED is "nukes dirty data".  Do you have a POSIX standard that
> > says POSIX MADV_DONTNEED should be similar to POSIX_FADV_DONTNEED?
> 
> Yes.  But this shouldn't be a problem.  Nobody says that nuking isn't OK.

You gave the definition as "the application does not need the data in
the near future".  If it were ok to nuke the data, the definition would
say "the application does not need the data".

-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: posix_fadvise
  2000-04-14 21:24         ` posix_fadvise Jamie Lokier
@ 2000-04-14 21:35           ` Ulrich Drepper
  2000-04-14 21:56             ` posix_fadvise Stephen C. Tweedie
  0 siblings, 1 reply; 6+ messages in thread
From: Ulrich Drepper @ 2000-04-14 21:35 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: VGER kernel list, linux-mm, Chuck Lever

Jamie Lokier <lk@tantalophile.demon.co.uk> writes:

> You gave the definition as "the application does not need the data in
> the near future".  If it were ok to nuke the data, the definition would
> say "the application does not need the data".

THere is no problem because the OS will recover.  I don't say it's an
optimal implementation but given that the name is used differently on
different OSes (at least the one without the POSIX_ prefix) people
will have to adjust themselves.

Of course I would prefer if the option in the Linux kernel could do
what POSIX says and simply add a new option for the current behaviour.
But nobody listens to me anyway so why bother.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: posix_fadvise
  2000-04-14 21:35           ` posix_fadvise Ulrich Drepper
@ 2000-04-14 21:56             ` Stephen C. Tweedie
  2000-04-15  2:49               ` posix_fadvise Ulrich Drepper
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen C. Tweedie @ 2000-04-14 21:56 UTC (permalink / raw)
  To: Ulrich Drepper; +Cc: Jamie Lokier, VGER kernel list, linux-mm, Chuck Lever

Hi,

On Fri, Apr 14, 2000 at 02:35:25PM -0700, Ulrich Drepper wrote:
> 
> Of course I would prefer if the option in the Linux kernel could do
> what POSIX says and simply add a new option for the current behaviour.
> But nobody listens to me anyway so why bother.

The current behaviour is consistent with a lot of other implementations,
and I've had very specific requests from application vendors that
Linux continue to behave the same way.  

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: posix_fadvise
  2000-04-14 21:56             ` posix_fadvise Stephen C. Tweedie
@ 2000-04-15  2:49               ` Ulrich Drepper
  0 siblings, 0 replies; 6+ messages in thread
From: Ulrich Drepper @ 2000-04-15  2:49 UTC (permalink / raw)
  To: Stephen C. Tweedie; +Cc: Jamie Lokier, VGER kernel list, linux-mm, Chuck Lever

"Stephen C. Tweedie" <sct@redhat.com> writes:

> The current behaviour is consistent with a lot of other implementations,
> and I've had very specific requests from application vendors that
> Linux continue to behave the same way.  

I've never suggested to remove the old behaviour.  Just implement the
other one as well or at least provide an appropriate constant/macro so
that I can use it.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2000-04-15  2:49 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <m38zyhgn2a.fsf@localhost.localnet>
     [not found] ` <20000414105811.B29138@pcep-jamie.cern.ch>
     [not found]   ` <m3snwofzo4.fsf@localhost.localnet>
2000-04-14 20:45     ` posix_fadvise Jamie Lokier
2000-04-14 20:56       ` posix_fadvise Ulrich Drepper
2000-04-14 21:24         ` posix_fadvise Jamie Lokier
2000-04-14 21:35           ` posix_fadvise Ulrich Drepper
2000-04-14 21:56             ` posix_fadvise Stephen C. Tweedie
2000-04-15  2:49               ` posix_fadvise Ulrich Drepper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox