On Tuesday 11 September 2007 16:03, Christoph Lameter wrote:
> 5. VM scalability
>Large block sizes mean less state keeping for the information being
>transferred. For a 1TB file one needs to handle 256 million page
>structs in the VM if one uses 4k page size. A 64k page size reduces
>
On Tue, Sep 11, 2007 at 04:52:19AM +1000, Nick Piggin wrote:
> The idea that there even _is_ a bug to fail when higher order pages
> cannot be allocated was also brushed aside by some people at the
> vm/fs summit. I don't know if those people had gone through the
> math about this, but it goes some
On Tue, 11 September 2007 04:52:19 +1000, Nick Piggin wrote:
> On Tuesday 11 September 2007 16:03, Christoph Lameter wrote:
>
> > 5. VM scalability
> >Large block sizes mean less state keeping for the information being
> >transferred. For a 1TB file one needs to handle 256 million page
> >
On Tuesday 11 September 2007 22:12, Jörn Engel wrote:
> On Tue, 11 September 2007 04:52:19 +1000, Nick Piggin wrote:
> > On Tuesday 11 September 2007 16:03, Christoph Lameter wrote:
> > > 5. VM scalability
> > >Large block sizes mean less state keeping for the information being
> > >transfe
On Tue, 2007-09-11 at 04:52 +1000, Nick Piggin wrote:
> On Tuesday 11 September 2007 16:03, Christoph Lameter wrote:
>
> > 5. VM scalability
> >Large block sizes mean less state keeping for the information being
> >transferred. For a 1TB file one needs to handle 256 million page
> >str
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Tuesday 11 September 2007 22:12, Jörn Engel wrote:
>> On Tue, 11 September 2007 04:52:19 +1000, Nick Piggin wrote:
>> > On Tuesday 11 September 2007 16:03, Christoph Lameter wrote:
>> > > 5. VM scalability
>> > >Large block sizes mean less state ke
Hi Mel,
On Tue, Sep 11, 2007 at 04:36:07PM +0100, Mel Gorman wrote:
> that increasing the pagesize like what Andrea suggested would lead to
> internal fragmentation problems. Regrettably we didn't discuss Andrea's
The config_page_shift guarantees the kernel stacks or whatever not
defragmentable a
On Wednesday 12 September 2007 01:36, Mel Gorman wrote:
> On Tue, 2007-09-11 at 04:52 +1000, Nick Piggin wrote:
> > On Tuesday 11 September 2007 16:03, Christoph Lameter wrote:
> > > 5. VM scalability
> > >Large block sizes mean less state keeping for the information being
> > >transferred.
On Tue, 2007-09-11 at 18:47 +0200, Andrea Arcangeli wrote:
> Hi Mel,
>
Hi,
> On Tue, Sep 11, 2007 at 04:36:07PM +0100, Mel Gorman wrote:
> > that increasing the pagesize like what Andrea suggested would lead to
> > internal fragmentation problems. Regrettably we didn't discuss Andrea's
>
> The
On Wednesday 12 September 2007 04:31, Mel Gorman wrote:
> On Tue, 2007-09-11 at 18:47 +0200, Andrea Arcangeli wrote:
> > Hi Mel,
>
> Hi,
>
> > On Tue, Sep 11, 2007 at 04:36:07PM +0100, Mel Gorman wrote:
> > > that increasing the pagesize like what Andrea suggested would lead to
> > > internal fragm
On Tuesday 11 September 2007 05:26:05 Nick Piggin wrote:
> On Wednesday 12 September 2007 04:31, Mel Gorman wrote:
> > On Tue, 2007-09-11 at 18:47 +0200, Andrea Arcangeli wrote:
> > > Hi Mel,
> >
> > Hi,
> >
> > > On Tue, Sep 11, 2007 at 04:36:07PM +0100, Mel Gorman wrote:
> > > > that increasing t
On Wednesday 12 September 2007 04:25, Maxim Levitsky wrote:
> Hi,
>
> I think that fundamental problem is no fragmentation/large pages/...
>
> The problem is the VM itself.
> The vm doesn't use virtual memory, thats all, that the problem.
> Although this will be probably linux 3.0, I think that th
Hi,
On Tue, Sep 11, 2007 at 07:31:01PM +0100, Mel Gorman wrote:
> Now, the worst case scenario for your patch is that a hostile process
> allocates large amount of memory and mlocks() one 4K page per 64K chunk
> (this is unlikely in practice I know). The end result is you have many
> 64KB regions
On Tue, 11 Sep 2007, Nick Piggin wrote:
> There is a limitation in the VM. Fragmentation. You keep saying this
> is a solved issue and just assuming you'll be able to fix any cases
> that come up as they happen.
>
> I still don't get the feeling you realise that there is a fundamental
> fragmenta
On Tue, 11 Sep 2007, Andrea Arcangeli wrote:
> Furthermore all the issues with writeprotect faults over MAP_PRIVATE
> regions will have to be addressed the same way with both approaches if
> we want real 100% 4k-granular backwards compatibility.
Could you be more specific as to why my patch does
On Tue, 11 Sep 2007, Jörn Engel 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 collision. I don't see anyone a
On Tue, 11 Sep 2007, Nick Piggin wrote:
> It would be interesting to craft an attack. If you knew roughly the layout
> and size of your dentry slab for example... maybe you could stat a whole
> lot of files, then open one and keep it open (maybe post the fd to a unix
> socket or something crazy!)
On Tue, 11 Sep 2007, Andrea Arcangeli wrote:
> But the whole point is that with the config_page_shift, Nick's worst
> case scenario can't happen by design regardless of defrag or not
> defrag. While it can _definitely_ happen with SGI design (regardless
> of any defrag thing). We can still try to
Odd. I keep arguing against the solution I prefer.
On Tue, 11 September 2007 21:20:52 +0200, Andrea Arcangeli wrote:
>
> The the problem with the slub fragmentation isn't a new problem, it
> happens in today kernels as well and at least the slab by design is
> meant to _defrag_ internally. So it
On Wednesday 12 September 2007 06:01, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
> > There is a limitation in the VM. Fragmentation. You keep saying this
> > is a solved issue and just assuming you'll be able to fix any cases
> > that come up as they happen.
> >
> > I still
On Tue, 11 September 2007 13:07:06 -0700, Christoph Lameter wrote:
>
> You may want to consider Mel's antifrag approaches which certainly
> decreases the chance of this occurring. Reclaim can open up the needed
> linear memory hole in a intentional way. The memory compaction approach
> can even
On Wednesday 12 September 2007 06:11, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
> > It would be interesting to craft an attack. If you knew roughly the
> > layout and size of your dentry slab for example... maybe you could stat a
> > whole lot of files, then open one and ke
On Tue, 11 Sep 2007, Jörn Engel wrote:
> What I'm starting to wonder about is where your approach has advantages
> over Andrea's. The chances of triggering something vaguely similar to
> Nick's worst case scenario are certainly higher for your solution. So
> unless there are other upsides it is
On Tue, 11 Sep 2007, Nick Piggin wrote:
> > I guess you would have to run that without my targeted slab reclaim
> > patchset? Otherwise the slab that are in the way could be reclaimed and
> > you could not produce your test case.
>
> I didn't realise you had patches to move pinned dentries, radix
On (11/09/07 11:44), Nick Piggin didst pronounce:
> On Wednesday 12 September 2007 01:36, Mel Gorman wrote:
> > On Tue, 2007-09-11 at 04:52 +1000, Nick Piggin wrote:
> > > On Tuesday 11 September 2007 16:03, Christoph Lameter wrote:
> > > > 5. VM scalability
> > > >Large block sizes mean less s
On Wednesday 12 September 2007 06:01, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
> > There is a limitation in the VM. Fragmentation. You keep saying this
> > is a solved issue and just assuming you'll be able to fix any cases
> > that come up as they happen.
> >
> > I still
On (11/09/07 12:26), Nick Piggin didst pronounce:
> On Wednesday 12 September 2007 04:31, Mel Gorman wrote:
> > On Tue, 2007-09-11 at 18:47 +0200, Andrea Arcangeli wrote:
> > > On Tue, Sep 11, 2007 at 04:36:07PM +0100, Mel Gorman wrote:
> > > > that increasing the pagesize like what Andrea suggeste
On (11/09/07 15:17), Nick Piggin didst pronounce:
> On Wednesday 12 September 2007 06:01, Christoph Lameter wrote:
> > On Tue, 11 Sep 2007, Nick Piggin wrote:
> > > There is a limitation in the VM. Fragmentation. You keep saying this
> > > is a solved issue and just assuming you'll be able to fix a
On Wednesday 12 September 2007 06:42, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
> > > I guess you would have to run that without my targeted slab reclaim
> > > patchset? Otherwise the slab that are in the way could be reclaimed and
> > > you could not produce your test case
On Tue, 11 Sep 2007, Mel Gorman wrote:
> > Well Christoph seems to still be spinning them as a solution for VM
> > scalability and first class support for making contiguous IOs, large
> > filesystem block sizes etc.
> >
>
> Yeah, I can't argue with you there. I was under the impression that we
>
On Tue, 11 Sep 2007, Nick Piggin wrote:
> I think I would have as good a shot as any to write a fragmentation
> exploit, yes. I think I've given you enough info to do the same, so I'd
> like to hear a reason why it is not a problem.
No you have not explained why the theoretical issues continue to
On Wednesday 12 September 2007 06:53, Mel Gorman wrote:
> On (11/09/07 11:44), Nick Piggin didst pronounce:
> However, this discussion belongs more with the non-existant-remove-slab
> patch. Based on what we've seen since the summits, we need a thorough
> analysis with benchmarks before making a f
On Wednesday 12 September 2007 07:41, Christoph Lameter wrote:
> On Tue, 11 Sep 2007, Nick Piggin wrote:
> > I think I would have as good a shot as any to write a fragmentation
> > exploit, yes. I think I've given you enough info to do the same, so I'd
> > like to hear a reason why it is not a prob
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 going against the bas
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.
>
> So how does lumpy reclaim, your slab patches, or anti-frag have
> much
On (11/09/07 14:48), Christoph Lameter didst pronounce:
> 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 filesy
On Wednesday 12 September 2007 07:48, 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 fi
On Tue, Sep 11, 2007 at 01:41:08PM -0700, Christoph Lameter wrote:
> The advantages of this approach over Andreas is basically that the 4k
> filesystems still can be used as is. 4k is useful for binaries and for
If you mean that with my approach you can't use a 4k filesystem as is,
that's not co
On Tue, 11 Sep 2007, Nick Piggin wrote:
> > Well its seems that we have different interpretations of what was agreed
> > on. My understanding was that the large blocksize patchset was okay
> > provided that I supply an acceptable mmap implementation and put a
> > warning in.
>
> Yes. I think we d
On Wed, 12 Sep 2007, Andrea Arcangeli wrote:
> On Tue, Sep 11, 2007 at 01:41:08PM -0700, Christoph Lameter wrote:
> > The advantages of this approach over Andreas is basically that the 4k
> > filesystems still can be used as is. 4k is useful for binaries and for
>
> If you mean that with my app
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 vmapping in places).
> >
> > I think they use vmapping because they have
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 vmappi
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
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 goi
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.
> >
>
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 vmappi
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 whil
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. That
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, 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 thi
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 gre
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 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 mag
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 sig
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. P
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
> overwhelmi
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 alloc
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 ha
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-kerne
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
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 p
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
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 lar
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
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 matt
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 ther
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 ca
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 y
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 s
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 f
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 wh
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 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 dent
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, 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
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 memo
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 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 (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 pa
[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 sil
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 updated
[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 t
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 i
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 guar
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 fallbac
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 ope
On (17/09/07 00:38), Goswin von Brederlow didst pronounce:
> [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
On (17/09/07 00:48), Goswin von Brederlow didst pronounce:
> [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
On (16/09/07 23:58), Goswin von Brederlow didst pronounce:
> [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:
On (16/09/07 23:31), Andrea Arcangeli didst pronounce:
> 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
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 are movable and reclaimable. You can see that f.e.
On Saturday 15 September 2007 03:52, Christoph Lameter wrote:
> 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 y
On Saturday 15 September 2007 04:08, Christoph Lameter wrote:
> 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 ord
1 - 100 of 145 matches
Mail list logo
