remind me, I may be able to re-execute the tests in a 4.16-rcX
before LSF/MM so you have other data to work with. Unfortunately, I'll
not be able to make LSF/MM this time due to personal commitments that
conflict and are unmovable.
--
Mel Gorman
SUSE Labs
not used for network traffic that
is not involved with swap. This means that under heavy swap load, it was
perfectly possible for unrelated traffic to get dropped for quite some
time.
--
Mel Gorman
SUSE Labs
Lespinasse
Sasha Levin
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
he program committee:
Storage:
James Bottomley
Martin Petersen
Christoph Hellwig
Filesystem:
Jeff Layton
Ric Wheeler
Jan Kara
Trond Myklebust
Theodore Ts'o
MM:
Rik van Riel
Michel Lespinasse
Sasha
On Wed, Jan 29, 2014 at 09:52:46PM -0700, Matthew Wilcox wrote:
> On Fri, Jan 24, 2014 at 10:57:48AM +0000, Mel Gorman wrote:
> > So far on the table is
> >
> > 1. major filesystem overhawl
> > 2. major vm overhawl
> > 3. use compound pages as they
On Thu, Jan 23, 2014 at 02:47:10PM -0600, Christoph Lameter wrote:
> On Wed, 22 Jan 2014, Mel Gorman wrote:
>
> > Large block support was proposed years ago by Christoph Lameter
> > (http://lwn.net/Articles/232757/). I think I was just getting started
> > in the community
; by the kernel and the MMU page size then I don't know but it would be a
> > fairly large amount of surgery and need a lot of design work. Minimally,
> > anything dealing with an MMU-sized amount of memory would now need to
> > deal with sub-pages and there would need to b
at extra work is needed (and how big is this
> piece of work)?
>
Offhand no idea. For fsblock, probably a similar amount of work than
had to be done in 2007 and I'd expect it would still require filesystem
awareness problems that Dave Chinner pointer out earlier. For large block,
it
On Wed, Jan 22, 2014 at 09:58:46AM -0500, Ric Wheeler wrote:
> On 01/22/2014 09:34 AM, Mel Gorman wrote:
> >On Wed, Jan 22, 2014 at 09:10:48AM -0500, Ric Wheeler wrote:
> >>On 01/22/2014 04:34 AM, Mel Gorman wrote:
> >>>On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric
On Wed, Jan 22, 2014 at 09:10:48AM -0500, Ric Wheeler wrote:
> On 01/22/2014 04:34 AM, Mel Gorman wrote:
> >On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote:
> >>One topic that has been lurking forever at the edges is the current
> >>4k limitation for fi
ould expect that a show-stopper for any proposal is requiring
high-order allocations to succeed for the system to behave correctly.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
MM:
Rik van Riel
Michel Lespinasse
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Dec 08, 2012 at 04:50:21PM -0800, Linus Torvalds wrote:
>
>
> On Sat, 8 Dec 2012, Mel Gorman wrote:
> >
> > Commit 8852aac2 (workqueue: mod_delayed_work_on() shouldn't queue timer on
> > 0 delay) is causing the following boot failure for me. Found by bisec
- not syncing: Fatal exception in interrupt
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On (14/12/07 13:07), Mark Lord didst pronounce:
>
>
> That (also) works for me here, regularly generating 64KB I/O segments with
> SLAB.
>
Brilliant. Thanks a lot Mark.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
Univers
%6d v: %8lu p: %8lu .",
ppfn, contig_count,
block_number, vpfn, ppfn);
contig_count = 1;
block_number++;
}
ppfn_last = ppfn;
}
print
== 0) {
perror("fread");
exit(EXIT_FAILURE);
}
ppfn = (unsigned long)pagemap_entry;
printf("vpfn = %8lu ppfn = %8lu\n", vpfn, ppfn);
}
close(pagemap_fd);
munmap(anonmapping, MAPSIZE);
page of the appropriate migrate type.
This patch restores behaviour of rmqueue_bulk() preserving the physical order
of pages returned by the allocator without incurring increased search costs for
anti-fragmentation.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
page_alloc.c | 11 +++
ysical ordering of pages returned. I'm setting up to run some
performance benchmarks of the candidate fix merged into the -mm tree to see
if the search shows up or not. I'm testing against 2.6.25-rc5 but it'll
take a few hours to complete.
--
Mel Gorman
Part-time Phd Student
19 matches
Mail list logo
