On Tue, 18 Sep 2007, Andrew Morton wrote:
> How hard would it be to handle the allocation failure in a more friendly
> manner? Say, if the allocation failed then point mapping->dirty_nodes at
> some global all-ones nodemask, and then special-case that nodemask in the
> freeing code?
Ack. However
On Tue, 18 Sep 2007, Ethan Solomita wrote:
> > Does it have to be atomic? atomic is weak and can fail.
> >
> > If some callers can do GFP_KERNEL and some can only do GFP_ATOMIC then we
> > should at least pass the gfp_t into this function so it can do the stronger
> > allocation when possible.
>
On Tue, 18 Sep 2007 17:51:49 -0700 Ethan Solomita <[EMAIL PROTECTED]> wrote:
> >
> >> +void cpuset_update_dirty_nodes(struct address_space *mapping,
> >> + struct page *page)
> >> +{
> >> + nodemask_t *nodes = mapping->dirty_nodes;
> >> + int node = page_to_nid(page);
> >> +
>
Andrew Morton wrote:
> On Tue, 11 Sep 2007 18:36:34 -0700
> Ethan Solomita <[EMAIL PROTECTED]> wrote:
>
>> Add a dirty map to struct address_space
>
> I get a tremendous number of rejects trying to wedge this stuff on top of
> Peter's mm-dirty-balancing-for-tasks changes. More rejects than I am
On Fri, 14 Sep 2007, Andrew Morton wrote:
> It'd be nice to see some discussion regarding the memory consumption of
> this patch and the associated tradeoffs.
On small NUMA system < 64 nodes you basically have an additional word
added to the address_space structure. On large NUMA we may have to
Satyam Sharma wrote:
> True, the other option could be to put the /pointer/ in there
> unconditionally,
> but that would slow down the MAX_NUMNODES <= BITS_PER_LONG case,
> which (after grepping through defconfigs) appears to be the common case on
> all archs other than ia64. So I think your ide
On 9/15/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 15 Sep 2007 05:17:48 +0530
> "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
>
> > > It's unobvious why the break point is at MAX_NUMNODES = BITS_PER_LONG and
> > > we might want to tweak that in the future. Yet another argument for
> > > c
On Sat, 15 Sep 2007 05:17:48 +0530
"Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> > It's unobvious why the break point is at MAX_NUMNODES = BITS_PER_LONG and
> > we might want to tweak that in the future. Yet another argument for
> > centralising this comparison.
>
> Looks like just an optimizatio
On 9/15/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Sep 2007 18:36:34 -0700
> Ethan Solomita <[EMAIL PROTECTED]> wrote:
> > The dirty map may be stored either directly in the mapping (for NUMA
> > systems with less then BITS_PER_LONG nodes) or separately allocated
> > for systems wit
On Tue, 11 Sep 2007 18:36:34 -0700
Ethan Solomita <[EMAIL PROTECTED]> wrote:
> Add a dirty map to struct address_space
I get a tremendous number of rejects trying to wedge this stuff on top of
Peter's mm-dirty-balancing-for-tasks changes. More rejects than I am
prepared to partially-fix so that
Add a dirty map to struct address_space
In a NUMA system it is helpful to know where the dirty pages of a mapping
are located. That way we will be able to implement writeout for applications
that are constrained to a portion of the memory of the system as required by
cpusets.
This patch implemen
Add a dirty map to struct address_space
In a NUMA system it is helpful to know where the dirty pages of a mapping
are located. That way we will be able to implement writeout for applications
that are constrained to a portion of the memory of the system as required by
cpusets.
This patch implement
12 matches
Mail list logo
