lkml.org 
[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] per-zone kswapd process
> Sorry, I don't buy that.
>
> a) It does not need to be architecture neutral.
>
> b) You surely need a way of communicating the discovered topology
> to userspace anyway.
>
> c) $EDITOR /etc/numa-layouf.conf
>
> d) $EDITOR /etc/kswapd.conf

I guess you could do that, but it seems overly complicated to me.

>> I think mbligh recently got the long-needed arch code in
>> for cpu to node... But I'm just not able to make the leap of faith that
>> memory detection is something that can ever comfortably be given to
>> userspace.
>
> A simple syscall which alows you to launch a kswapd instance against
> a group of zones on any group of CPUs provides complete generality
> and flexibility to userspace. And it is architecture neutral.
>
> If it really is incredibly hard to divine the topology from userspace
> then you need to fix that up. Provide the topology to userspace.
> Which has the added benefit of providing, umm, the topology to userspace ;)

Can we make a simple default of 1 per node, which is what 99%
of people want, and then make it more complicated later if people
complain? It's really pretty easy:

for (node = 0; node < numnodes; ++node) {
kswapd = kick_off_kswapd_for_node(node);
kswapd->cpus_allowed = node_to_cpus(node);
}

Or whatever the current cpus_allowed method is. All we seem to need
is node_to_cpus ... I can give that to you tommorow with no problem,
it's trivial.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.193 / U:0.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site