Mel wrote:
> I have not read up on cpuset before so I am assuming you are talking about
> http://www.bullopensource.org/cpuset/ so correct me if I am wrong.
Yes - that. See also the kernel doc file:
Documentation/cpusets.txt
> I agree that if cpuset is not
> widely used, it should not
On Thu, 10 Mar 2005, Dave Hansen wrote:
> On Thu, 2005-03-10 at 09:22 -0800, Paul Jackson wrote:
> > In particular, I am working on preparing a patch proposal for a policy
> > that would kill a task rather than invoke the swapper. In
> > mm/page_alloc.c __alloc_pages(), if one gets down to the
On Thu, 10 Mar 2005, Dave Hansen wrote:
On Thu, 2005-03-10 at 09:22 -0800, Paul Jackson wrote:
In particular, I am working on preparing a patch proposal for a policy
that would kill a task rather than invoke the swapper. In
mm/page_alloc.c __alloc_pages(), if one gets down to the point of
Mel wrote:
I have not read up on cpuset before so I am assuming you are talking about
http://www.bullopensource.org/cpuset/ so correct me if I am wrong.
Yes - that. See also the kernel doc file:
Documentation/cpusets.txt
I agree that if cpuset is not
widely used, it should not be
Dave wrote:
> Shouldn't a particular task know what the policy should be when it is
> launched?
No ... but not necessarily because it isn't known yet, but rather also
because it might be imposed earlier in the job creation, before the
actual task hierarchy is manifest. This point goes to the
On Thu, 2005-03-10 at 12:11 -0800, Paul Jackson wrote:
> Dave wrote:
> > Perhaps default policies inherited from a cpuset, but overridden by
> > other APIs would be a good compromise.
>
> Perhaps. The madvise() and numa calls (mbind, set_mempolicy) only
> affect the current task, as is usually
Dave wrote:
> Perhaps default policies inherited from a cpuset, but overridden by
> other APIs would be a good compromise.
Perhaps. The madvise() and numa calls (mbind, set_mempolicy) only
affect the current task, as is usually appropriate for calls that allow
specification of specific address
On Thu, 2005-03-10 at 09:22 -0800, Paul Jackson wrote:
> In particular, I am working on preparing a patch proposal for a policy
> that would kill a task rather than invoke the swapper. In
> mm/page_alloc.c __alloc_pages(), if one gets down to the point of being
> about to kick the swapper, if
Mel Gorman, responding to Dave Hansen
> > The other thing is that we'll probably have to be a lot more strict
> > about how the allocations fall back. Some users will probably prefer to
> > kill an application rather than let a kernel allocation fall back into a
> > user memory area.
> >
>
>
On Thu, 2005-03-10 at 14:31 +, Mel Gorman wrote:
> > > There are 2 kinds of sections: user and kernel. The traditional
> > > ZONE_HIGHMEM is full of user sections (except for vmalloc).
>
> And PTEs if configured to be allocated from high memory. I have not double
> checked but I don't think
On Mon, 7 Mar 2005, Dave Hansen wrote:
> On Mon, 2005-03-07 at 19:39 +, Mel Gorman wrote:
> > The placement policy patch should now be more Hotplug-friendly and I
> > would like to hear from the Hotplug people if they have more
> > requirements of this patch.
>
> It looks like most of what we
On Mon, 7 Mar 2005, Dave Hansen wrote:
On Mon, 2005-03-07 at 19:39 +, Mel Gorman wrote:
The placement policy patch should now be more Hotplug-friendly and I
would like to hear from the Hotplug people if they have more
requirements of this patch.
It looks like most of what we need is
On Thu, 2005-03-10 at 14:31 +, Mel Gorman wrote:
There are 2 kinds of sections: user and kernel. The traditional
ZONE_HIGHMEM is full of user sections (except for vmalloc).
And PTEs if configured to be allocated from high memory. I have not double
checked but I don't think they can
Mel Gorman, responding to Dave Hansen
The other thing is that we'll probably have to be a lot more strict
about how the allocations fall back. Some users will probably prefer to
kill an application rather than let a kernel allocation fall back into a
user memory area.
That will be a
On Thu, 2005-03-10 at 09:22 -0800, Paul Jackson wrote:
In particular, I am working on preparing a patch proposal for a policy
that would kill a task rather than invoke the swapper. In
mm/page_alloc.c __alloc_pages(), if one gets down to the point of being
about to kick the swapper, if this
Dave wrote:
Perhaps default policies inherited from a cpuset, but overridden by
other APIs would be a good compromise.
Perhaps. The madvise() and numa calls (mbind, set_mempolicy) only
affect the current task, as is usually appropriate for calls that allow
specification of specific address
On Thu, 2005-03-10 at 12:11 -0800, Paul Jackson wrote:
Dave wrote:
Perhaps default policies inherited from a cpuset, but overridden by
other APIs would be a good compromise.
Perhaps. The madvise() and numa calls (mbind, set_mempolicy) only
affect the current task, as is usually
Dave wrote:
Shouldn't a particular task know what the policy should be when it is
launched?
No ... but not necessarily because it isn't known yet, but rather also
because it might be imposed earlier in the job creation, before the
actual task hierarchy is manifest. This point goes to the
On Mon, 2005-03-07 at 19:39 +, Mel Gorman wrote:
> The placement policy patch should now be more Hotplug-friendly and I
> would like to hear from the Hotplug people if they have more
> requirements of this patch.
It looks like most of what we need is there already. There are two
things that
Hi,
The following two emails contain the latest version of the placement policy
for the binary buddy allocator to reduce fragmentation and the prezeroing
patch. The changelogs are with the patches.
The placement policy patch should now be more Hotplug-friendly and I would like
to hear from the
Hi,
The following two emails contain the latest version of the placement policy
for the binary buddy allocator to reduce fragmentation and the prezeroing
patch. The changelogs are with the patches.
The placement policy patch should now be more Hotplug-friendly and I would like
to hear from the
On Mon, 2005-03-07 at 19:39 +, Mel Gorman wrote:
The placement policy patch should now be more Hotplug-friendly and I
would like to hear from the Hotplug people if they have more
requirements of this patch.
It looks like most of what we need is there already. There are two
things that
22 matches
Mail list logo
