On Sun, 16 Sep 2007, Jörn Engel wrote:
I bet! My (false) assumption was the same as Goswin's. If non-movable
pages are clearly seperated from movable ones and will evict movable
ones before polluting further mixed superpages, Nick's scenario would be
nearly infinitely impossible.
On Sun, 16 Sep 2007, Nick Piggin wrote:
fsblock doesn't need any of those hacks, of course.
Nor does mine for the low orders that we are considering. For order
MAX_ORDER this is unavoidable since the page allocator cannot manage such
large pages. It can be used for lower order if
On Mon, 17 Sep 2007, Bernd Schmidt wrote:
Christoph Lameter wrote:
True. That is why we want to limit the number of unmovable allocations and
that is why ZONE_MOVABLE exists to limit those. However, unmovable
allocations are already rare today. The overwhelming majority of allocations
On Sun, 16 Sep 2007, Nick Piggin wrote:
So if you argue that vmap is a downside, then please tell me how you
consider the -ENOMEM of your approach to be better?
That is again pretty undifferentiated. Are we talking about low page
In general.
There is no -ENOMEM approach. Lower order
On Fri, Sep 14, 2007 at 06:48:55AM +1000, Nick Piggin wrote:
> On Thursday 13 September 2007 12:01, Nick Piggin wrote:
> > On Thursday 13 September 2007 23:03, David Chinner wrote:
> > > Then just do operations on directories with lots of files in them
> > > (tens of thousands). Every directory
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> You ignore one other bit, when "/usr/bin/free" says 1G is free, with
> config-page-shift it's free no matter what, same goes for not mlocked
> cache. With variable order page cache, /usr/bin/free becomes mostly a
> lie as long as there's no 4k
[EMAIL PROTECTED] (Mel Gorman) writes:
> On (16/09/07 17:08), Andrea Arcangeli didst pronounce:
>> zooming in I see red pixels all over the squares mized with green
>> pixels in the same square. This is exactly what happens with the
>> variable order page cache and that's why it provides zero
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sun, 16 Sep 2007, Jörn Engel wrote:
>>
>> My approach is to have one for mount points and ramfs/tmpfs/sysfs/etc.
>> which are pinned for their entire lifetime and another for regular
>> files/inodes. One could take a three-way approach and have
>>
On Mon, 17 September 2007 00:06:24 +0200, Goswin von Brederlow wrote:
>
> How probable is it that the dentry is needed again? If you copy it and
> it is not needed then you wasted time. If you throw it out and it is
> needed then you wasted time too. Depending on the probability one of
> the two
[EMAIL PROTECTED] (Mel Gorman) writes:
> On (15/09/07 02:31), Goswin von Brederlow didst pronounce:
>> Mel Gorman <[EMAIL PROTECTED]> writes:
>>
>> > On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote:
>> >> Nick Piggin <[EMAIL PROTECTED]> writes:
>> >>
>> >> > In my attack, I cause
Jörn Engel <[EMAIL PROTECTED]> writes:
> On Sun, 16 September 2007 00:30:32 +0200, Andrea Arcangeli wrote:
>>
>> Movable? I rather assume all slab allocations aren't movable. Then
>> slab defrag can try to tackle on users like dcache and inodes. Keep in
>> mind that with the exception of
[EMAIL PROTECTED] (Mel Gorman) writes:
> On (15/09/07 14:14), Goswin von Brederlow didst pronounce:
>> Andrew Morton <[EMAIL PROTECTED]> writes:
>>
>> > On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote:
>> >
>> >> While I agree with your concern, those numbers are quite
On (16/09/07 19:53), J?rn Engel didst pronounce:
> On Sat, 15 September 2007 01:44:49 -0700, Andrew Morton wrote:
> > On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote:
> >
> > > While I agree with your concern, those numbers are quite silly. The
> > > chances of 99.8% of
On Sun, Sep 16, 2007 at 09:54:18PM +0100, Mel Gorman wrote:
> The 16MB is the size of a hugepage, the size of interest as far as I am
> concerned. Your idea makes sense for large block support, but much less
> for huge pages because you are incurring a cost in the general case for
> something that
On (15/09/07 02:31), Goswin von Brederlow didst pronounce:
> Mel Gorman <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote:
> >> Nick Piggin <[EMAIL PROTECTED]> writes:
> >>
> >> > In my attack, I cause the kernel to allocate lots of unmovable
> >> >
On (16/09/07 17:08), Andrea Arcangeli didst pronounce:
> On Sun, Sep 16, 2007 at 03:54:56PM +0200, Goswin von Brederlow wrote:
> > Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> >
> > > On Sat, Sep 15, 2007 at 10:14:44PM +0200, Goswin von Brederlow wrote:
> > >> - Userspace allocates a lot of
On (16/09/07 20:50), Andrea Arcangeli didst pronounce:
> On Sun, Sep 16, 2007 at 07:15:04PM +0100, Mel Gorman wrote:
> > Except now as I've repeatadly pointed out, you have internal fragmentation
> > problems. If we went with the SLAB, we would need 16MB slabs on PowerPC for
> > example to get the
On Sun, Sep 16, 2007 at 07:15:04PM +0100, Mel Gorman wrote:
> Except now as I've repeatadly pointed out, you have internal fragmentation
> problems. If we went with the SLAB, we would need 16MB slabs on PowerPC for
> example to get the same sort of results and a lot of copying and moving when
On Sun, 16 Sep 2007, Jörn Engel wrote:
>
> My approach is to have one for mount points and ramfs/tmpfs/sysfs/etc.
> which are pinned for their entire lifetime and another for regular
> files/inodes. One could take a three-way approach and have
> always-pinned, often-pinned and rarely-pinned.
>
On Sun, 16 September 2007 11:15:36 -0700, Linus Torvalds wrote:
> On Sun, 16 Sep 2007, Jörn Engel wrote:
> >
> > I have been toying with the idea of having seperate caches for pinned
> > and movable dentries. Downside of such a patch would be the number of
> > memcpy() operations when moving
On Sun, 16 Sep 2007, Jörn Engel wrote:
>
> I have been toying with the idea of having seperate caches for pinned
> and movable dentries. Downside of such a patch would be the number of
> memcpy() operations when moving dentries from one cache to the other.
Totally inappropriate.
I bet 99% of
On (15/09/07 17:51), Andrea Arcangeli didst pronounce:
> On Sat, Sep 15, 2007 at 02:14:42PM +0200, Goswin von Brederlow wrote:
> > I keep coming back to the fact that movable objects should be moved
> > out of the way for unmovable ones. Anything else just allows
>
> That's incidentally exactly
On (15/09/07 14:14), Goswin von Brederlow didst pronounce:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote:
> >
> >> While I agree with your concern, those numbers are quite silly. The
> >> chances of 99.8% of pages being
On Sat, 15 September 2007 01:44:49 -0700, Andrew Morton wrote:
> On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote:
>
> > While I agree with your concern, those numbers are quite silly. The
> > chances of 99.8% of pages being free and the remaining 0.2% being
> > perfectly
On Sun, 16 September 2007 00:30:32 +0200, Andrea Arcangeli wrote:
>
> Movable? I rather assume all slab allocations aren't movable. Then
> slab defrag can try to tackle on users like dcache and inodes. Keep in
> mind that with the exception of updatedb, those inodes/dentries will
> be pinned and
On Sun, Sep 16, 2007 at 03:54:56PM +0200, Goswin von Brederlow wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> writes:
>
> > On Sat, Sep 15, 2007 at 10:14:44PM +0200, Goswin von Brederlow wrote:
> >> - Userspace allocates a lot of memory in those slabs.
> >
> > If with slabs you mean slab/slub, I
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Sat, Sep 15, 2007 at 10:14:44PM +0200, Goswin von Brederlow wrote:
>> - Userspace allocates a lot of memory in those slabs.
>
> If with slabs you mean slab/slub, I can't follow, there has never been
> a single byte of userland memory allocated
Andrea Arcangeli [EMAIL PROTECTED] writes:
On Sat, Sep 15, 2007 at 10:14:44PM +0200, Goswin von Brederlow wrote:
- Userspace allocates a lot of memory in those slabs.
If with slabs you mean slab/slub, I can't follow, there has never been
a single byte of userland memory allocated there since
On Sun, Sep 16, 2007 at 03:54:56PM +0200, Goswin von Brederlow wrote:
Andrea Arcangeli [EMAIL PROTECTED] writes:
On Sat, Sep 15, 2007 at 10:14:44PM +0200, Goswin von Brederlow wrote:
- Userspace allocates a lot of memory in those slabs.
If with slabs you mean slab/slub, I can't follow,
On Sun, 16 September 2007 00:30:32 +0200, Andrea Arcangeli wrote:
Movable? I rather assume all slab allocations aren't movable. Then
slab defrag can try to tackle on users like dcache and inodes. Keep in
mind that with the exception of updatedb, those inodes/dentries will
be pinned and you
On Sat, 15 September 2007 01:44:49 -0700, Andrew Morton wrote:
On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel [EMAIL PROTECTED] wrote:
While I agree with your concern, those numbers are quite silly. The
chances of 99.8% of pages being free and the remaining 0.2% being
perfectly spread
On (15/09/07 14:14), Goswin von Brederlow didst pronounce:
Andrew Morton [EMAIL PROTECTED] writes:
On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel [EMAIL PROTECTED] wrote:
While I agree with your concern, those numbers are quite silly. The
chances of 99.8% of pages being free and the
On (15/09/07 17:51), Andrea Arcangeli didst pronounce:
On Sat, Sep 15, 2007 at 02:14:42PM +0200, Goswin von Brederlow wrote:
I keep coming back to the fact that movable objects should be moved
out of the way for unmovable ones. Anything else just allows
That's incidentally exactly what the
On Sun, 16 Sep 2007, Jörn Engel wrote:
I have been toying with the idea of having seperate caches for pinned
and movable dentries. Downside of such a patch would be the number of
memcpy() operations when moving dentries from one cache to the other.
Totally inappropriate.
I bet 99% of all
On Sun, 16 September 2007 11:15:36 -0700, Linus Torvalds wrote:
On Sun, 16 Sep 2007, Jörn Engel wrote:
I have been toying with the idea of having seperate caches for pinned
and movable dentries. Downside of such a patch would be the number of
memcpy() operations when moving dentries
On Sun, 16 Sep 2007, Jörn Engel wrote:
My approach is to have one for mount points and ramfs/tmpfs/sysfs/etc.
which are pinned for their entire lifetime and another for regular
files/inodes. One could take a three-way approach and have
always-pinned, often-pinned and rarely-pinned.
We
On Sun, Sep 16, 2007 at 07:15:04PM +0100, Mel Gorman wrote:
Except now as I've repeatadly pointed out, you have internal fragmentation
problems. If we went with the SLAB, we would need 16MB slabs on PowerPC for
example to get the same sort of results and a lot of copying and moving when
Well
On (16/09/07 20:50), Andrea Arcangeli didst pronounce:
On Sun, Sep 16, 2007 at 07:15:04PM +0100, Mel Gorman wrote:
Except now as I've repeatadly pointed out, you have internal fragmentation
problems. If we went with the SLAB, we would need 16MB slabs on PowerPC for
example to get the same
On (16/09/07 17:08), Andrea Arcangeli didst pronounce:
On Sun, Sep 16, 2007 at 03:54:56PM +0200, Goswin von Brederlow wrote:
Andrea Arcangeli [EMAIL PROTECTED] writes:
On Sat, Sep 15, 2007 at 10:14:44PM +0200, Goswin von Brederlow wrote:
- Userspace allocates a lot of memory in those
On (15/09/07 02:31), Goswin von Brederlow didst pronounce:
Mel Gorman [EMAIL PROTECTED] writes:
On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote:
Nick Piggin [EMAIL PROTECTED] writes:
In my attack, I cause the kernel to allocate lots of unmovable
allocations
and
On Sun, Sep 16, 2007 at 09:54:18PM +0100, Mel Gorman wrote:
The 16MB is the size of a hugepage, the size of interest as far as I am
concerned. Your idea makes sense for large block support, but much less
for huge pages because you are incurring a cost in the general case for
something that may
On (16/09/07 19:53), J?rn Engel didst pronounce:
On Sat, 15 September 2007 01:44:49 -0700, Andrew Morton wrote:
On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel [EMAIL PROTECTED] wrote:
While I agree with your concern, those numbers are quite silly. The
chances of 99.8% of pages being
[EMAIL PROTECTED] (Mel Gorman) writes:
On (15/09/07 14:14), Goswin von Brederlow didst pronounce:
Andrew Morton [EMAIL PROTECTED] writes:
On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel [EMAIL PROTECTED] wrote:
While I agree with your concern, those numbers are quite silly. The
chances
Jörn Engel [EMAIL PROTECTED] writes:
On Sun, 16 September 2007 00:30:32 +0200, Andrea Arcangeli wrote:
Movable? I rather assume all slab allocations aren't movable. Then
slab defrag can try to tackle on users like dcache and inodes. Keep in
mind that with the exception of updatedb, those
[EMAIL PROTECTED] (Mel Gorman) writes:
On (15/09/07 02:31), Goswin von Brederlow didst pronounce:
Mel Gorman [EMAIL PROTECTED] writes:
On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote:
Nick Piggin [EMAIL PROTECTED] writes:
In my attack, I cause the kernel to allocate
On Mon, 17 September 2007 00:06:24 +0200, Goswin von Brederlow wrote:
How probable is it that the dentry is needed again? If you copy it and
it is not needed then you wasted time. If you throw it out and it is
needed then you wasted time too. Depending on the probability one of
the two is
Linus Torvalds [EMAIL PROTECTED] writes:
On Sun, 16 Sep 2007, Jörn Engel wrote:
My approach is to have one for mount points and ramfs/tmpfs/sysfs/etc.
which are pinned for their entire lifetime and another for regular
files/inodes. One could take a three-way approach and have
[EMAIL PROTECTED] (Mel Gorman) writes:
On (16/09/07 17:08), Andrea Arcangeli didst pronounce:
zooming in I see red pixels all over the squares mized with green
pixels in the same square. This is exactly what happens with the
variable order page cache and that's why it provides zero guarantees
Andrea Arcangeli [EMAIL PROTECTED] writes:
You ignore one other bit, when /usr/bin/free says 1G is free, with
config-page-shift it's free no matter what, same goes for not mlocked
cache. With variable order page cache, /usr/bin/free becomes mostly a
lie as long as there's no 4k fallback (like
On Fri, Sep 14, 2007 at 06:48:55AM +1000, Nick Piggin wrote:
On Thursday 13 September 2007 12:01, Nick Piggin wrote:
On Thursday 13 September 2007 23:03, David Chinner wrote:
Then just do operations on directories with lots of files in them
(tens of thousands). Every directory operation
On Sat, Sep 15, 2007 at 10:14:44PM +0200, Goswin von Brederlow wrote:
> How does that help? Will slabs move objects around to combine two
1. It helps providing a few guarantees: when you run "/usr/bin/free"
you won't get a random number, but a strong _guarantee_. That ram will
be available no
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Sat, Sep 15, 2007 at 02:14:42PM +0200, Goswin von Brederlow wrote:
>> I keep coming back to the fact that movable objects should be moved
>> out of the way for unmovable ones. Anything else just allows
>
> That's incidentally exactly what the slab
On Sat, Sep 15, 2007 at 02:14:42PM +0200, Goswin von Brederlow wrote:
> I keep coming back to the fact that movable objects should be moved
> out of the way for unmovable ones. Anything else just allows
That's incidentally exactly what the slab does, no need to reinvent
the wheel for that, it's
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote:
>
>> While I agree with your concern, those numbers are quite silly. The
>> chances of 99.8% of pages being free and the remaining 0.2% being
>> perfectly spread across all 2MB
On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote:
> While I agree with your concern, those numbers are quite silly. The
> chances of 99.8% of pages being free and the remaining 0.2% being
> perfectly spread across all 2MB large_pages are lower than those of SHA1
> creating
On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel [EMAIL PROTECTED] wrote:
While I agree with your concern, those numbers are quite silly. The
chances of 99.8% of pages being free and the remaining 0.2% being
perfectly spread across all 2MB large_pages are lower than those of SHA1
creating a
Andrew Morton [EMAIL PROTECTED] writes:
On Tue, 11 Sep 2007 14:12:26 +0200 Jörn Engel [EMAIL PROTECTED] wrote:
While I agree with your concern, those numbers are quite silly. The
chances of 99.8% of pages being free and the remaining 0.2% being
perfectly spread across all 2MB large_pages
On Sat, Sep 15, 2007 at 02:14:42PM +0200, Goswin von Brederlow wrote:
I keep coming back to the fact that movable objects should be moved
out of the way for unmovable ones. Anything else just allows
That's incidentally exactly what the slab does, no need to reinvent
the wheel for that, it's an
Andrea Arcangeli [EMAIL PROTECTED] writes:
On Sat, Sep 15, 2007 at 02:14:42PM +0200, Goswin von Brederlow wrote:
I keep coming back to the fact that movable objects should be moved
out of the way for unmovable ones. Anything else just allows
That's incidentally exactly what the slab does, no
On Sat, Sep 15, 2007 at 10:14:44PM +0200, Goswin von Brederlow wrote:
How does that help? Will slabs move objects around to combine two
1. It helps providing a few guarantees: when you run /usr/bin/free
you won't get a random number, but a strong _guarantee_. That ram will
be available no matter
Christoph Lameter <[EMAIL PROTECTED]> writes:
> On Fri, 14 Sep 2007, Christoph Lameter wrote:
>
>> an -ENOMEM. Given the quantities of pages on todays machine--a 1 G machine
>
> s/1G/1T/ Sigh.
>
>> has 256 milllion 4k pages--and the unmovable ratios we see today it
>
> 256k for 1G.
256k == 64
Mel Gorman <[EMAIL PROTECTED]> writes:
> On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>>
>> > In my attack, I cause the kernel to allocate lots of unmovable allocations
>> > and deplete movable groups. I theoretically then only need to
On Fri, 14 Sep 2007, Christoph Lameter wrote:
> an -ENOMEM. Given the quantities of pages on todays machine--a 1 G machine
s/1G/1T/ Sigh.
> has 256 milllion 4k pages--and the unmovable ratios we see today it
256k for 1G.
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, 14 Sep 2007, Nick Piggin wrote:
> However fsblock can do everything that higher order pagecache can
> do in terms of avoiding vmap and giving contiguous memory to block
> devices by opportunistically allocating higher orders of pages, and falling
> back to vmap if they cannot be
On Fri, 14 Sep 2007, Nick Piggin wrote:
> > > [*] ok, this isn't quite true because if you can actually put a hard
> > > limit on unmovable allocations then anti-frag will fundamentally help --
> > > get back to me on that when you get patches to move most of the obvious
> > > ones.
> >
> > We
On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > In my attack, I cause the kernel to allocate lots of unmovable allocations
> > and deplete movable groups. I theoretically then only need to keep a
> > small number (1/2^N) of these
Hi,
Nick Piggin <[EMAIL PROTECTED]> writes:
> In my attack, I cause the kernel to allocate lots of unmovable allocations
> and deplete movable groups. I theoretically then only need to keep a
> small number (1/2^N) of these allocations around in order to DoS a
> page allocation of order N.
I'm
On Thursday 13 September 2007 09:17, Christoph Lameter wrote:
> On Wed, 12 Sep 2007, Nick Piggin wrote:
> > I will still argue that my approach is the better technical solution for
> > large block support than yours, I don't think we made progress on that.
> > And I'm quite sure we agreed at the
On Thursday 13 September 2007 09:06, Christoph Lameter wrote:
> On Wed, 12 Sep 2007, Nick Piggin wrote:
> > So lumpy reclaim does not change my formula nor significantly help
> > against a fragmentation attack. AFAIKS.
>
> Lumpy reclaim improves the situation significantly because the
>
On Thursday 13 September 2007 12:01, Nick Piggin wrote:
> On Thursday 13 September 2007 23:03, David Chinner wrote:
> > Then just do operations on directories with lots of files in them
> > (tens of thousands). Every directory operation will require at
> > least one vmap in this situation - e.g. a
On Thursday 13 September 2007 09:06, Christoph Lameter wrote:
On Wed, 12 Sep 2007, Nick Piggin wrote:
So lumpy reclaim does not change my formula nor significantly help
against a fragmentation attack. AFAIKS.
Lumpy reclaim improves the situation significantly because the
overwhelming
On Thursday 13 September 2007 12:01, Nick Piggin wrote:
On Thursday 13 September 2007 23:03, David Chinner wrote:
Then just do operations on directories with lots of files in them
(tens of thousands). Every directory operation will require at
least one vmap in this situation - e.g. a
On Thursday 13 September 2007 09:17, Christoph Lameter wrote:
On Wed, 12 Sep 2007, Nick Piggin wrote:
I will still argue that my approach is the better technical solution for
large block support than yours, I don't think we made progress on that.
And I'm quite sure we agreed at the VM
Hi,
Nick Piggin [EMAIL PROTECTED] writes:
In my attack, I cause the kernel to allocate lots of unmovable allocations
and deplete movable groups. I theoretically then only need to keep a
small number (1/2^N) of these allocations around in order to DoS a
page allocation of order N.
I'm
On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote:
Nick Piggin [EMAIL PROTECTED] writes:
In my attack, I cause the kernel to allocate lots of unmovable allocations
and deplete movable groups. I theoretically then only need to keep a
small number (1/2^N) of these allocations
On Fri, 14 Sep 2007, Nick Piggin wrote:
[*] ok, this isn't quite true because if you can actually put a hard
limit on unmovable allocations then anti-frag will fundamentally help --
get back to me on that when you get patches to move most of the obvious
ones.
We have this hard
On Fri, 14 Sep 2007, Nick Piggin wrote:
However fsblock can do everything that higher order pagecache can
do in terms of avoiding vmap and giving contiguous memory to block
devices by opportunistically allocating higher orders of pages, and falling
back to vmap if they cannot be satisfied.
On Fri, 14 Sep 2007, Christoph Lameter wrote:
an -ENOMEM. Given the quantities of pages on todays machine--a 1 G machine
s/1G/1T/ Sigh.
has 256 milllion 4k pages--and the unmovable ratios we see today it
256k for 1G.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Mel Gorman [EMAIL PROTECTED] writes:
On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote:
Nick Piggin [EMAIL PROTECTED] writes:
In my attack, I cause the kernel to allocate lots of unmovable allocations
and deplete movable groups. I theoretically then only need to keep a
small
Christoph Lameter [EMAIL PROTECTED] writes:
On Fri, 14 Sep 2007, Christoph Lameter wrote:
an -ENOMEM. Given the quantities of pages on todays machine--a 1 G machine
s/1G/1T/ Sigh.
has 256 milllion 4k pages--and the unmovable ratios we see today it
256k for 1G.
256k == 64 pages for 1GB
On Thu, 13 Sep 2007, Mel Gorman wrote:
> Surely, we'll be able to detect the situation where the memory is really
> contiguous as a fast path and have a slower path where fragmentation was
> a problem.
Yes I have a draft here now of a virtual compound page solution that I am
testing with SLUB.
On Thursday 13 September 2007 23:03, David Chinner wrote:
> On Thu, Sep 13, 2007 at 03:23:21AM +1000, Nick Piggin wrote:
> > Well, it may not be easy to _fix_, but it's easy to try a few
> > improvements ;)
> >
> > How do I make an image and run a workload that will coerce XFS into
> > doing a
On Thu, Sep 13, 2007 at 03:23:21AM +1000, Nick Piggin wrote:
> On Thursday 13 September 2007 11:49, David Chinner wrote:
> > On Wed, Sep 12, 2007 at 01:27:33AM +1000, Nick Piggin wrote:
>
> > > I just gave 4 things which combined might easily reduce xfs vmap overhead
> > > by several orders of
On (12/09/07 16:17), Christoph Lameter didst pronounce:
> On Wed, 12 Sep 2007, Nick Piggin wrote:
>
> > I will still argue that my approach is the better technical solution for
> > large
> > block support than yours, I don't think we made progress on that. And I'm
> > quite sure we agreed at the
On Thursday 13 September 2007 11:49, David Chinner wrote:
> On Wed, Sep 12, 2007 at 01:27:33AM +1000, Nick Piggin wrote:
> > I just gave 4 things which combined might easily reduce xfs vmap overhead
> > by several orders of magnitude, all without changing much code at all.
>
> Patches would be
On Thursday 13 September 2007 11:49, David Chinner wrote:
On Wed, Sep 12, 2007 at 01:27:33AM +1000, Nick Piggin wrote:
I just gave 4 things which combined might easily reduce xfs vmap overhead
by several orders of magnitude, all without changing much code at all.
Patches would be greatly
On (12/09/07 16:17), Christoph Lameter didst pronounce:
On Wed, 12 Sep 2007, Nick Piggin wrote:
I will still argue that my approach is the better technical solution for
large
block support than yours, I don't think we made progress on that. And I'm
quite sure we agreed at the VM summit
On Thu, Sep 13, 2007 at 03:23:21AM +1000, Nick Piggin wrote:
On Thursday 13 September 2007 11:49, David Chinner wrote:
On Wed, Sep 12, 2007 at 01:27:33AM +1000, Nick Piggin wrote:
I just gave 4 things which combined might easily reduce xfs vmap overhead
by several orders of magnitude,
On Thursday 13 September 2007 23:03, David Chinner wrote:
On Thu, Sep 13, 2007 at 03:23:21AM +1000, Nick Piggin wrote:
Well, it may not be easy to _fix_, but it's easy to try a few
improvements ;)
How do I make an image and run a workload that will coerce XFS into
doing a significant
On Thu, 13 Sep 2007, Mel Gorman wrote:
Surely, we'll be able to detect the situation where the memory is really
contiguous as a fast path and have a slower path where fragmentation was
a problem.
Yes I have a draft here now of a virtual compound page solution that I am
testing with SLUB.
On Wed, Sep 12, 2007 at 01:27:33AM +1000, Nick Piggin wrote:
> > IOWs, we already play these vmap harm-minimisation games in the places
> > where we can, but still the overhead is high and something we'd prefer
> > to be able to avoid.
>
> I don't think you've looked nearly far enough with all
On Wed, 12 Sep 2007, Nick Piggin wrote:
> I will still argue that my approach is the better technical solution for large
> block support than yours, I don't think we made progress on that. And I'm
> quite sure we agreed at the VM summit not to rely on your patches for
> VM or IO scalability.
The
On Wed, 12 Sep 2007, Nick Piggin wrote:
> In my attack, I cause the kernel to allocate lots of unmovable allocations
> and deplete movable groups. I theoretically then only need to keep a
> small number (1/2^N) of these allocations around in order to DoS a
> page allocation of order N.
True.
On Wednesday 12 September 2007 10:00, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
> > Yes. I think we differ on our interpretations of "okay". In my
> > interpretation, it is not OK to use this patch as a way to solve VM or FS
> > or IO scalability issues, especially not
On Wednesday 12 September 2007 11:49, David Chinner wrote:
> On Tue, Sep 11, 2007 at 04:00:17PM +1000, Nick Piggin wrote:
> > > > OTOH, I'm not sure how much buy-in there was from the filesystems
> > > > guys. Particularly Christoph H and XFS (which is strange because they
> > > > already do
On Wednesday 12 September 2007 07:52, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
> > > No you have not explained why the theoretical issues continue to exist
> > > given even just considering Lumpy Reclaim in .23 nor what effect the
> > > antifrag patchset would have.
> >
>
Christoph Lameter wrote:
On Tue, 11 Sep 2007, Nick Piggin wrote:
But that's not my place to say, and I'm actually not arguing that high
order pagecache does not have uses (especially as a practical,
shorter-term solution which is unintrusive to filesystems).
So no, I don't think I'm really
On Tue, Sep 11, 2007 at 05:04:41PM -0700, Christoph Lameter wrote:
> I would think that your approach would be slower since you always have to
> populate 1 << N ptes when mmapping a file? Plus there is a lot of wastage
I don't have to populate them, I could just map one at time. The only
reason
On Wednesday 12 September 2007 11:49, David Chinner wrote:
> On Tue, Sep 11, 2007 at 04:00:17PM +1000, Nick Piggin wrote:
> > > > OTOH, I'm not sure how much buy-in there was from the filesystems
> > > > guys. Particularly Christoph H and XFS (which is strange because they
> > > > already do
Christoph Lameter wrote:
On Tue, 11 Sep 2007, Nick Piggin wrote:
But that's not my place to say, and I'm actually not arguing that high
order pagecache does not have uses (especially as a practical,
shorter-term solution which is unintrusive to filesystems).
So no, I don't think I'm really
101 - 200 of 290 matches
Mail list logo
