> > > This piece here only does conversion to a string representation so it
> > > should not be affected by locking issues. Processes need to do proper
> > > locking when using the conversion functions.
> >
> > It's useless.
>
> So your point of view is that there will be no control and monitor
On Thu, 4 Aug 2005, Andi Kleen wrote:
> > You designed a NUMA API to control a process memory access patterns
> > without the ability to view or modify the policies in use?
>
> Processes internally can get the information if they want.
> Externally I didn't expose it intentionally to avoid locki
On Wed, 3 Aug 2005, Andi Kleen wrote:
> I really hate this whole /proc//numa_policy thing. /proc//maps
> was imho always a desaster (hard to parse, slow etc.). Also external
> access of NUMA policies has interesting locking issues. I intentionally
> didn't add something like that when I designed t
On Thu, Aug 04, 2005 at 07:11:36AM -0700, Christoph Lameter wrote:
> On Wed, 3 Aug 2005, Andi Kleen wrote:
>
> > I really hate this whole /proc//numa_policy thing. /proc//maps
> > was imho always a desaster (hard to parse, slow etc.). Also external
> > access of NUMA policies has interesting locki
On Tue, 2 Aug 2005, Paul Jackson wrote:
> Christoph wrote:
> > Could you rework the patch to all of that?
>
> Next week - I am on vacation at the moment.
I have done all the fixups necessary . Just the candy that you wanted
is missing.
-
To unsubscribe from this list: send the line "unsubs
On Mon, Aug 01, 2005 at 11:48:55AM -0700, Christoph Lameter wrote:
> On Sat, 30 Jul 2005, Paul Jackson wrote:
>
> > Would it make sense for you to do the same thing, when displaying
> > mempolicies in /proc//numa_policy?
>
> Here is a new rev of the conversions patch. Thanks for all the feedback:
Christoph wrote:
> Could you rework the patch to all of that?
Next week - I am on vacation at the moment.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe fr
Christoph wrote:
> Ok. The str_to_mpol function needs to be executed from the task whose
> memory policies are to be displayed but why would mpol_to_str need that?
You are probably right. I doubt mpol_to_str needs that. I was
probably painting with too wide a brush.
> I am quite concerned abo
On Mon, 1 Aug 2005, Paul Jackson wrote:
> There should probably be comments that these routines must
> execute in the context of the task whose mempolicies are
> being displayed or modified.
Ok. The str_to_mpol function needs to be executed from the task whose
memory policies are to be displayed
Could you rework the patch to all of that? Seems that you have a clear
vision as to where to go.
On Mon, 1 Aug 2005, Paul Jackson wrote:
> Christoph wrote:
> > New version without the magic numbers ...
>
> Good.
>
> ===
>
> How about replacing:
>
> static const char *policy_types[] = { "de
Christoph wrote:
> New version without the magic numbers ...
Good.
===
How about replacing:
static const char *policy_types[] = { "default", "prefer", "bind",
"interleave" };
with:
static const char *policy_types[] = {
[MPOL_DEFAULT]= "default",
[MPOL_PREFERRED] = "p
New version without the magic numbers ...
---
String conversions for memory policy
This patch adds two new functions to mm/mempolicy.c that allow the conversion
of a memory policy to a textual representation and vice versa.
Syntax of textual representation:
default
preferred=
bind=
interleave=
On Mon, 1 Aug 2005, Paul Jackson wrote:
> Christoph wrote:
> > you need to create multiple
> > levels of directories in /proc//xx
>
> You do?
>
> Where's the new multiple directory levels in the two files:
>
> /proc//numa_policy # contains one word
> /proc//numa_nodelist
Christoph wrote:
> you need to create multiple
> levels of directories in /proc//xx
You do?
Where's the new multiple directory levels in the two files:
/proc//numa_policy # contains one word
/proc//numa_nodelist # contains one nodelist
There are some obvious negat
On Mon, 1 Aug 2005, Paul Jackson wrote:
> In your related patch, you show how to merge this display of mempolicy
> into the new /proc//smap (rss size of each memory area) file.
> But this smap file (or, as you renamed it, emap file) is read-only,
> so far as I can tell. It enables display of info
Ok - its definitely getting shorter and sweeter. Good.
There are quite a few small magic numbers - is there someway to code
these out? See also my comment below, mentioning kernel/power/main.c.
Changing one of the strings should not break the code until the
corresponding magic string length numb
The full patchset that also includes the modifications to
/proc// smaps to support outputting numa information can be found at
ftp://ftp.kernel.org/pub/linux/kernel/people/christoph/numa/2.6.13-rc4-mm1.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On Sat, 30 Jul 2005, Paul Jackson wrote:
> Would it make sense for you to do the same thing, when displaying
> mempolicies in /proc//numa_policy?
Here is a new rev of the conversions patch. Thanks for all the feedback:
---
String conversions for memory policy
This patch adds two new functions
On Sat, 30 Jul 2005, Paul Jackson wrote:
> Christoph wrote:
> > It sets all the node bits by looping over all zones using
> > zone->zone_pgdat->node_id.
>
> Yes, for 'all zones' in the mempolicy.
>
> Would it make sense for you to do the same thing, when displaying
> mempolicies in /proc//numa_
Christoph wrote:
> It sets all the node bits by looping over all zones using
> zone->zone_pgdat->node_id.
Yes, for 'all zones' in the mempolicy.
Would it make sense for you to do the same thing, when displaying
mempolicies in /proc//numa_policy?
--
I won't rest till it's the
On Sat, 30 Jul 2005, Paul Jackson wrote:
> Christoph wrote:
> > The problem is how to convert them back for display. Match the zones in
> > groups of three to the zones in a node and then print out the node?
>
> What does get_mempolicy(2) do? I doubt it assumes groups of three.
> See further th
Christoph wrote:
> The problem is how to convert them back for display. Match the zones in
> groups of three to the zones in a node and then print out the node?
What does get_mempolicy(2) do? I doubt it assumes groups of three.
See further the case for MPOL_BIND, in mm/mempolicy.c:get_zonemask()
> Who else would know details about memory policies?
Andi Kleen. I do not know of anyone else who can
respond to the points you observe.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.
Christoph wrote:
> this could be construet as a single string
I said "single token." I meant as in a single word, not a string of
multiple tokens having its own internal syntax. Heck - if by 'string'
you just mean a sequence of bytes, then I could construe any data
representation as a 'string'.
On Sat, 30 Jul 2005, Paul Jackson wrote:
> I suspect you should do the same. I doubt we want to expose
> zones to user space here.
The problem is how to convert them back for display. Match the zones in
groups of three to the zones in a node and then print out the node?
> I will leave it to A
Christoph wrote:
> Strangely mpol_new converts a node bit mask into a
> list of zones.
It's not strange. The numa interface calls mbind, set_mempolicy
and get_mempolicy, between kernel and user, don't deal in zones.
They deal in nodes.
I suspect you should do the same. I doubt we want to expos
On Fri, 29 Jul 2005, Paul Jackson wrote:
> Oh - I should have mentioned this before - if you are displaying and
> parsing node lists (nodemask_t) then there are wrappers for these
> bitmap routines in linux/nodemask.h:
>
> * int nodemask_scnprintf(buf, len, mask) Format nodemask for printing
>
On Fri, 29 Jul 2005, Paul Jackson wrote:
> Once we have a clear description of this syntax in the record,
> I anticipate raising as an issue that this syntax does not have a
> single integer or string token value per file (or at most, an array
> or list of comparable integer values).
The current
Oh - I should have mentioned this before - if you are displaying and
parsing node lists (nodemask_t) then there are wrappers for these
bitmap routines in linux/nodemask.h:
* int nodemask_scnprintf(buf, len, mask) Format nodemask for printing
* int nodemask_parse(ubuf, ulen, mask) Parse ascii s
Christoph wrote:
> you could have a look at my initial patch which actually
> included a description of the syntax
Yes - I could (I did actually).
Something like that should be part of the record here. Not everyone
has your earlier linux-mm email thread right at hand.
> Diff to use bitmap_scn
On Fri, 29 Jul 2005, Paul Jackson wrote:
> My first suspicion on reading it is that it might partially duplicate
> some string conversion code and syntax that is already present in
> the kernel for other purposes. For example the nodelists might
> replicate the lists of numbers supported by bitma
Hmmm ... my previous reaction to this conversion code, when you posted
an ancestor of this patch on linux-mm, got buried in the crypically
terse term 'complex API', and that thread went on to discuss matters
of greater substance, such as whether one thread could or should
manipulate the memory poli
32 matches
Mail list logo
