linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Badovinatz <tabmowzo@us.ibm.com>
To: Mika Kukkonen <mika@osdl.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	cgl_discussion@osdl.org
Subject: Re: [cgl_discussion] Re: OSDL CGL-WG draft specs available forreview
Date: Wed, 23 Apr 2003 15:03:52 -0700	[thread overview]
Message-ID: <3EA70DC8.187CDD25@us.ibm.com> (raw)
In-Reply-To: 1051122743.7515.97.camel@miku-t21-redhat.koti

Mika Kukkonen wrote:
> 
> On Wed, 2003-04-23 at 09:49, Christoph Hellwig wrote:
> > >    4.10 Force unmount (2) 2 Experimental Availability Core
> (...)
> > This is very hard to get right.  What the expermintel implementation
> > you're referring to?
> 
> This feature was mentioned in v1.1 spec, so some distributions already
> provide "experimental" versions of this feature. There are no Open
> Source projects I know of, though.

It is hard to get right, I personally cannot vouch for Solaris 8 or
Veritas (VxFS) having gotten it right.  We list it because of the
expressed desire to control file system mountings in clustered
environments.  One option is to shut down a node where the file system
is mounted, but for various reasons you would like a finer level of
control.

MontaVista claims support (see http://www.mvista.com/tech3.html) in
their Carrier Grade Edition Linux product release.  The 'Experimental'
is because this does exist, but I don't know how well it works, and
whether it's been proposed for mainstream inclusion.

> 
> > >    6.8 Page flushing 3 Experimental Performance Core
> (...)
> > I don't see how you want to implement this.  The fundamental VM object
> > for page flushing is struct address_space and it's in no say related to
> > processes.
> 
> I'll let somebody wiser than me to comment on this one, as I do not
> recall the reasoning behind this feature right know ;-)

The goal of this requirement is to allow the applications running on the
system to have deep control of the allocation of system resources.  In
response to some stimulus they can decide they want their allocated
pages released via this hypothetical flush.

A better analogue might be to madvise() and munmap(), although
generalized beyond mmap'ped pages.  In other words, the phrasing needs
to be improved here to be more accurate.  Since most of the text is
mine, and not the folks who've worked with me on it, blame me.

As to implementation, it is 'Experimental' because support exists for
some kinds of pages, ala madvise().  For the more generic case, I see
your point.  In part, we convey this making it priority 3 to allow time
to think on it, but we also don't want to limit possible solutions,
rather identify the need and help inspire the effort.


> > >    Reference projects:
> > >      * Implemented in NGPT: [94]http://www-124.ibm.com/pthreads/.
> >
> > Well, NGPT is maintaince only mode and I doubt there's much chance to see
> > this ever in glibc/ngpt.  I'd rather check this with Ullrich before adding
> > it to the spec..
> 
> Yes, we follow what is happening around. Really the requirement is just
> to get POSIX threads, if it gets done by NPTL we are OK with that. NGPT
> is mentioned because some distros currently ship with it and so from
> CGL viewpoint fulfill this requirement with NGPT.

Note that NGPT already implemented some specific interfaces [Robust
Mutexes] that are not part of Posix threads (rather, part of Solaris
(Unix International) threads in this case), and this function was
identified as being very important for compatibility for many existing
carrier applications.

I believe that Ulrich has already commented negatively on this support
in glibc/nptl, because it isn't POSIX.  But I'm uncomfortable completely
dropping this from the spec as we're trying to identify requirements as
viewed by some class of users (i.e., carrier applications.)  I can see
an adjustment of priority or other recognition (it's a 1, make it a 2,
and let the discussions play out over time.)

Peter
--
Peter R. Badovinatz aka 'Wombat' -- IBM Linux Technology Center
preferred: tabmowzo@us.ibm.com / alternate: wombat@us.ibm.com
These are my opinions and absolutely not official opinions of IBM, Corp.

  parent reply	other threads:[~2003-04-23 21:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-22 20:46 OSDL CGL-WG draft specs available for review Mika Kukkonen
2003-04-22 20:55 ` Christoph Hellwig
2003-04-22 21:22   ` [cgl_discussion] " Mika Kukkonen
2003-04-22 21:25     ` Christoph Hellwig
2003-04-23 16:18       ` Mika Kukkonen
2003-04-23 16:26         ` Christoph Hellwig
2003-04-23 16:49 ` Christoph Hellwig
2003-04-23 18:32   ` [cgl_discussion] " Mika Kukkonen
2003-04-23 20:22     ` Christoph Hellwig
2003-04-23 22:03     ` Peter Badovinatz [this message]
2003-04-24  9:39   ` Carl-Daniel Hailfinger
2003-04-24  9:46     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EA70DC8.187CDD25@us.ibm.com \
    --to=tabmowzo@us.ibm.com \
    --cc=cgl_discussion@osdl.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).