Matt Mackall wrote:
The version of SLOB in -mm always scans its free list from the
beginning, which results in small allocations and free segments
clustering at the beginning of the list over time. This causes the
average search to scan over a large stretch at the beginning on each
allocation.
B
Introduce ticket lock spinlocks for x86-64 which are FIFO. The implementation
is described in the comments. The straight-line lock/unlock instruction
sequence is slightly slower than the dec based locks on modern x86 CPUs,
however the difference is quite small on Core2 and Opteron when working out
Hi,
These patches are not exactly complete yet (haven't tested many config
combinations or converted other architectures), but I want to post it
now to get consensus on whether and how to clean up the lockbreak stuff
in particular.
It gets in the way because ticket spinlocks shouldn't be just rep
On Fri, Jul 13, 2007 at 04:56:10PM +0100, Mel Gorman wrote:
> On (12/07/07 22:32), Mel Gorman didst pronounce:
>
> > > Should we at least go for
> > >
> > > add-__gfp_movable-for-callers-to-flag-allocations-from-high-memory-that-may-be-migrated.patch
> > > create-the-zone_movable-zone.patch
> > >
David Chinner wrote:
On Thu, Jul 12, 2007 at 10:54:57AM +1000, Nick Piggin wrote:
Andrew Morton wrote:
The fault-vs-invalidate race fix. I have belatedly learned that these
need
more work, so their state is uncertain.
The more work may turn out being too much for you (although it is
Andrew Morton wrote:
mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
mm-merge-nopfn-into-fault.patch
convert-hugetlbfs-to-use-vm_ops-fault.patch
mm-remove-legacy-cruft.patch
mm-debug-check-for-the-fault-vs-invalidate-race.pa
Pekka J Enberg wrote:
Hi Christoph,
On Wed, 11 Jul 2007, Christoph Lameter wrote:
Of course you are the maintainer but you only authored a single patch
which was the original submission in all the time that SLOB was in the
tree. I keep having to clean up the allocator that has--according to
Christoph Hellwig wrote:
On Tue, Jul 10, 2007 at 11:41:19AM -0700, Andrew Morton wrote:
I'd support an ununofficial rule that submitters of new syscalls also raise
a patch against LTP, come to that...
s/ununofficial//, please. And extend this to every new kernel interface
that's not bound t
Ray Lee wrote:
As an honest question, what's it going to take here? If I were to
write something that watched the task stats at process exit (cool
feature, that), and recorded the IO wait time or some such, and showed
it was lower with a kernel with the prefetch, would *that* get us some
forward
Ray Lee wrote:
On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
>> OK that's a good data point. It would be really good to be able to
>> do an analysis on your overnight IO patterns and the corresponding
>> memory reclaim behaviour and see why things are gett
Ray Lee wrote:
On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Matthew Hawkins wrote:
> On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Anyhow with swap prefetch, applications that may have been sitting
> there idle for a while become responsive in the single-d
Matthew Hawkins wrote:
On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
Anyhow with swap prefetch, applications that may have been sitting
there idle for a while become responsive in the single-digit seconds
rather than double-digit or worse. The same goes for a morning wakeup
(ie after n
On Tue, Jul 10, 2007 at 07:26:10PM -0700, Christoph Lameter wrote:
> On Wed, 11 Jul 2007, Nick Piggin wrote:
>
> > BTW. some advanced congestion algorithms like HBO may find these ticket
> > locks useful because you can see immediately how many CPUs are contending
> > the
On Tue, Jul 10, 2007 at 12:11:45PM -0500, Dave McCracken wrote:
> On Tuesday 10 July 2007, Nick Piggin wrote:
> > On Tue, Jul 10, 2007 at 09:29:45AM -0500, Dave McCracken wrote:
> > > I find myself wondering what "sufficiently convincing noises" are. I
> > &g
On Tue, Jul 10, 2007 at 01:52:47PM -0700, Christoph Lameter wrote:
> On Sun, 8 Jul 2007, Andi Kleen wrote:
>
> > I would say the main drawback of switchable and queued locks
> > would be also that they require a larger spinlock_t thus increasing
> > cache usage
>
> Right. Zoran Radovic has shown
Mathieu Desnoyers wrote:
* Matt Mackall ([EMAIL PROTECTED]) wrote:
On Wed, Jul 11, 2007 at 10:02:23AM +1000, Nick Piggin wrote:
I like this patch a lot. Even if we don't add the underlying mechanism
right now, adding migration_disable as an alias for preempt_disable
will much better doc
Matt Mackall wrote:
On Fri, Jul 06, 2007 at 04:12:10PM +1000, Nick Piggin wrote:
Mathieu Desnoyers wrote:
Thread Migration Preemption
This patch adds the ability to protect critical sections from migration to
another CPU without disabling preemption.
This will be useful to minimize the
On Tue, Jul 10, 2007 at 09:29:45AM -0500, Dave McCracken wrote:
> On Tuesday 10 July 2007, Mel Gorman wrote:
> > > Mel's page allocator work. Might merge this, but I'm still not hearing
> > > sufficiently convincing noises from a sufficient number of people over
> > > this.
> >
> > This is a lon
On Tue, Jul 10, 2007 at 11:20:43AM +0100, Mel Gorman wrote:
> >
> > Mel's page allocator work. Might merge this, but I'm still not hearing
> > sufficiently convincing noises from a sufficient number of people over
> > this.
> >
>
> This is a long on-going story. It bounces between people who
Pekka Enberg wrote:
Hi Nick,
Pekka J Enberg wrote:
> That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
> debugging is disabled.
On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Interesting. What kernel version are you using?
Linus' git head
Håvard Skinnemoen wrote:
On 7/10/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
The only remaining known bug is arguably a problem in nommu that SLOB
shouldn't be papering over.
I've got another one for you: SLOB ignores ARCH_KMALLOC_MINALIGN so
using SLOB in combination with DMA and non-cohere
Pekka J Enberg wrote:
Curious, /proc/meminfo immediately after boot shows:
SLUB (debugging enabled):
(none):~# cat /proc/meminfo
MemTotal:30260 kB
MemFree: 22096 kB
SLUB (debugging disabled):
(none):~# cat /proc/meminfo
MemTotal:30276 kB
MemFree: 22244 kB
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
It is reasonable to expect some help from maintainers, but I notice you
didn't even CC the SLOB maintainer in the patch to remove SLOB! So maybe
if you tried working a bit closer with him you could get better results?
Matt Mackall wrote:
On Tue, Jul 10, 2007 at 11:58:44AM +1000, Nick Piggin wrote:
Just a fancy way of saying roughly that memory waste will increase as
the size of the system increases. But that aspect of it I think is
not really a problem for non-tiny systems anyway because the waste
tends
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
I don't see any problems with maintaining SLOB. It is simple enough
that I was able to write a userspace test harness for it and hack
away at it after reading the code the first time for half an hour or
so. It is nothing
Christoph Lameter wrote:
On Tue, 10 Jul 2007, Nick Piggin wrote:
O(n) memory savings? What is that?
Allocate n things and your memory waste is proportional to n (well that's
O(n) waste, so I guess by savings I mean that SLOB's memory saving compared
to SLUB are proportional to n
Christoph Lameter wrote:
On Mon, 9 Jul 2007, Andrew Morton wrote:
I think the advantage that SLOB generates here is pretty minimal and is
easily offset by the problems of maintaining SLOB.
I don't get it. Have you got agreement from the small memory people
that the advantages of SLOB are pre
Christoph Lameter wrote:
On Mon, 9 Jul 2007, Nick Piggin wrote:
A reason for retaining slob would be that it has some O(n) memory saving
due to better packing, etc. Indeed that was the reason for merging it in
the first place. If slob no longer retains that advantage (wrt slub) then
we no
Al Boldi wrote:
Pavel Machek wrote:
In the end, you'll get rid of freezer problems, but will have two
kernels to care about, and certainly more conventional design. I do
not think I have time to try that (and don't think freezer problems
are _that_ bad in the first place), but some interested
On Mon, Jul 09, 2007 at 05:59:47PM -0700, Christoph Lameter wrote:
> On Tue, 10 Jul 2007, Nick Piggin wrote:
>
> > > Hmmm I did not notice that yet but then I have not done much work
> > > there.
> >
> > Notice what?
>
> The bad code for the buf
On Mon, Jul 09, 2007 at 10:14:06AM -0700, Christoph Lameter wrote:
> On Sun, 24 Jun 2007, Nick Piggin wrote:
>
> > Firstly, what is the buffer layer? The buffer layer isn't really a
> > buffer layer as in the buffer cache of unix: the block device cache
> > is u
Pekka Enberg wrote:
Hi Nick,
On 7/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
SLOB contains several significant O(1) and also O(n) memory savings that
are so far impossible-by-design for SLUB. They are: slab external
fragmentation is significantly reduced; kmalloc internal fragmentat
Nick Piggin wrote:
Benjamin Herrenschmidt wrote:
On Mon, 2007-07-09 at 19:29 +1000, Nick Piggin wrote:
They could just #define one to the other though, there are only a
small
number of them. Is there a downside to not making them distinct? i386
for example probably would just keep doing a
Benjamin Herrenschmidt wrote:
On Mon, 2007-07-09 at 19:29 +1000, Nick Piggin wrote:
They could just #define one to the other though, there are only a
small
number of them. Is there a downside to not making them distinct? i386
for example probably would just keep doing a tlb flush for fork and
Benjamin Herrenschmidt wrote:
On Mon, 2007-07-09 at 17:39 +1000, Nick Piggin wrote:
Would it be better off to start off with a new API for this? The
mmu gather I think is traditionally entirely for dealing with
page removal...
It would be weird because the new API would mostly duplicate
Benjamin Herrenschmidt wrote:
Use mmu_gather for fork() instead of flush_tlb_mm()
This patch uses an mmu_gather for copying page tables instead of
flush_tlb_mm(). This allows archs like ppc32 with hash table to
avoid walking the page tables a second time to invalidate hash
entries, and to only f
Nick Piggin wrote:
Jeremy Maitin-Shepard wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Yes, I have a rough idea about how page reclaim works. But I just
mean it would not be trivial to load the new kernel into physically
discontiguous memory. Possible of course, but I don't thi
Jeremy Maitin-Shepard wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Yes, I have a rough idea about how page reclaim works. But I just
mean it would not be trivial to load the new kernel into physically
discontiguous memory. Possible of course, but I don't think kexec or
the setup
Jeremy Maitin-Shepard wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
This is the Morton method, isn't it? :) I remember it sounding like a
very good idea when he brought it up, but I can't remember the details
of why it was rejected or what the problems were.
Perhaps he
Nick Piggin wrote:
Jeremy Maitin-Shepard wrote:
Al Boldi <[EMAIL PROTECTED]> writes:
Pavel Machek wrote:
We are stuck with refrigerator for now, and at least for hibernation,
I don't see any feasible alternative.
Feasible alternative?
I posted such an alternative to
Jeremy Maitin-Shepard wrote:
Al Boldi <[EMAIL PROTECTED]> writes:
Pavel Machek wrote:
We are stuck with refrigerator for now, and at least for hibernation,
I don't see any feasible alternative.
Feasible alternative?
I posted such an alternative to the list a short time ago: hibenratin
Andrew Morton wrote:
On Sun, 8 Jul 2007 09:51:19 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
A year ago the -rt kernel defaulted to the SLOB for a few releases, and
barring some initial scalability issues (which were solved in -rt) it
worked pretty well on generic PCs, so i dont buy the 'it
Michal Piotrowski wrote:
Hi Flavio,
On 09/07/07, Flavio Curti <[EMAIL PROTECTED]> wrote:
Hello
I have a problem with a server running 2.6.22rc4.
Jul 8 00:19:13 dorade.cyberlink.ch EFLAGS: 00210046
(2.6.22-rc7-dorade #1)
Is this a regression?
The machine panics
after some days of ru
On Sun, Jul 08, 2007 at 01:18:10PM +0200, Andi Kleen wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > I made some tests of the queued spinlock code using userspace test code on
> > 64-bit processors. I believe the xadd based code no longer has any
> > t
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
I said exactly the same thing last time this came up. I would love to
remove code if its functionality can be adequately replaced by
existing code, but I think your reasons for removing SLOB aren't that
good, and just
Rusty Russell wrote:
Matt wrote:
This lets it get shared outside of proc/ and linked in only when needed.
Erk, this really belongs in the mm dir. You can use "lib-y +=
pagewalk.o" there, and it seems to work as well as doing it in lib.
+1 from me, again :)
--
SUSE Labs, Novell Inc.
-
To
Ingo Molnar wrote:
(added Matt to the Cc: list)
* Christoph Lameter <[EMAIL PROTECTED]> wrote:
Maintenance of slab allocators becomes a problem as new features for
allocators are developed. The SLOB allocator in particular has been
lagging behind in many ways in the past:
- Had no support
Steven Rostedt wrote:
On Fri, 2007-07-06 at 16:12 +1000, Nick Piggin wrote:
Mathieu Desnoyers wrote:
migration_disable();
local_inc(&__get_cpu_var(&my_local_t_var));
migration_enable();
[...]
This seems like way too much stuff to add just for this type of thing. Why
not just
I made some tests of the queued spinlock code using userspace test code on
64-bit processors. I believe the xadd based code no longer has any theoretical
memory ordering problems.
The tests were done on 3 different architectures of different speeds and
vintages (so not really comparable between co
Mathieu Desnoyers wrote:
Thread Migration Preemption
This patch adds the ability to protect critical sections from migration to
another CPU without disabling preemption.
This will be useful to minimize the amount of preemption disabling for the -rt
patch. It will help leveraging improvements br
KAMEZAWA Hiroyuki wrote:
On Thu, 05 Jul 2007 13:19:41 +1000
Nick Piggin <[EMAIL PROTECTED]> wrote:
From what I can work out, it is something like "at this point the page
should be uptodate, so at least the icache won't contain *inconsistent*
data, just old data which users
KAMEZAWA Hiroyuki wrote:
On Thu, 05 Jul 2007 12:04:23 +1000
Nick Piggin <[EMAIL PROTECTED]> wrote:
In my understanding :
PG_arch_1 is used for showing "there is no inconsistent data on any level of
cache". PG_uptodate is used for showing "this page includes the newest
KAMEZAWA Hiroyuki wrote:
On Wed, 04 Jul 2007 16:31:06 +1000
Nick Piggin <[EMAIL PROTECTED]> wrote:
The only thing I noticed when I looked at the code is that some places
may not have flushed icache when they should have? Did you get them all?
I think that I added flush_icache_page()
KAMEZAWA Hiroyuki wrote:
This is a experimental patch for fixing icache flush race of ia64(Montecito).
Problem Description:
Montecito, new ia64 processor, has separated L2 i-cache and d-cache,
and i-cache and d-cache is not consistent in automatic way.
L1 cache is also separated but L1 D-cache
Linus Torvalds wrote:
Nick,
call me a worry-wart, but I slept on this, and started worrying..
On Tue, 26 Jun 2007, Linus Torvalds wrote:
So try it with just a byte counter, and test some stupid micro-benchmark
on both a P4 and a Core 2 Duo, and if it's in the noise, maybe we can make
it the
On Thu, Jun 28, 2007 at 08:20:31AM -0400, Chris Mason wrote:
> On Thu, Jun 28, 2007 at 04:44:43AM +0200, Nick Piggin wrote:
> >
> > That's true but I don't think an extent data structure means we can
> > become too far divorced from the pagecache or the native blo
On Thu, Jun 28, 2007 at 08:35:48AM +1000, David Chinner wrote:
> On Wed, Jun 27, 2007 at 07:50:56AM -0400, Chris Mason wrote:
> > Lets look at a typical example of how IO actually gets done today,
> > starting with sys_write():
> >
> > sys_write(file, buffer, 1MB)
> > for each page:
> > prepar
Linus Torvalds wrote:
On Wed, 27 Jun 2007, Nick Piggin wrote:
I don't know why my unlock sequence should be that much slower? Unlocked
mov vs unlocked add? Definitely in dumb micro-benchmark testing it wasn't
twice as slow (IIRC).
Oh, that releasing "add" can be un
On Tue, Jun 26, 2007 at 08:34:49AM -0400, Chris Mason wrote:
> On Tue, Jun 26, 2007 at 07:23:09PM +1000, David Chinner wrote:
> > On Tue, Jun 26, 2007 at 01:55:11PM +1000, Nick Piggin wrote:
>
> [ ... fsblocks vs extent range mapping ]
>
> > iomaps can double as range loc
Linus Torvalds wrote:
On Tue, 26 Jun 2007, Nick Piggin wrote:
Hmm, not that I have a strong opinion one way or the other, but I
don't know that they would encourage bad code. They are not going to
reduce latency under a locked section, but will improve determinism
in the contended
On Tue, Jun 26, 2007 at 02:33:35PM -0700, Randy Dunlap wrote:
> On Tue, 26 Jun 2007 14:23:20 -0700 Andrew Morton wrote:
>
> > On Tue, 26 Jun 2007 15:48:58 -0500
> > Dave Kleikamp <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 2007-06-26 at 13:32 -0700, Andrew Morton wrote:
> > > > On Fri, 15 Jun 20
On Tue, Jun 26, 2007 at 07:23:09PM +1000, David Chinner wrote:
> On Tue, Jun 26, 2007 at 01:55:11PM +1000, Nick Piggin wrote:
> > >
> > >Realistically, this is not about "filesystem blocks", this is
> > >about file offset to disk blocks. i.e. it's a
Linus Torvalds wrote:
On Thu, 21 Jun 2007, Eric Dumazet wrote:
This reminds me Nick's proposal of 'queued spinlocks' 3 months ago
Maybe this should be re-considered ? (unlock is still a non atomic op,
so we dont pay the serializing cost twice)
No. The point is simple:
IF YOU NEED
Matt Mackall wrote:
On Tue, Jun 26, 2007 at 02:06:15PM +1000, Nick Piggin wrote:
Yoshinori Sato wrote:
At Fri, 22 Jun 2007 09:56:35 -0500,
Matt Mackall wrote:
On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
Because the page which SLOB allocator got does not have PG_slab
Yoshinori Sato wrote:
At Fri, 22 Jun 2007 09:56:35 -0500,
Matt Mackall wrote:
On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
Because the page which SLOB allocator got does not have PG_slab,
This is for a NOMMU system?
Yes.
You're using an old kernel with an old versi
David Chinner wrote:
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
I'm announcing "fsblock" now because it is quite intrusive and so I'd
like to get some thoughts about significantly changing this core part
of the kernel.
Can you rename it to something
Neil Brown wrote:
On Tuesday June 26, [EMAIL PROTECTED] wrote:
Chris Mason wrote:
The block device pagecache isn't special, and certainly isn't that much
code. I would suggest keeping it buffer head specific and making a
second variant that does only fsblocks. This is mostly to keep the
sem
Chris Mason wrote:
On Sun, Jun 24, 2007 at 03:46:13AM +0200, Nick Piggin wrote:
Rewrite the buffer layer.
Overall, I like the basic concepts, but it is hard to track the locking
rules. Could you please write them up?
Yeah I will do that.
Thanks for taking a look. One thing I am thinking
Christoph Hellwig wrote:
On Sun, Jun 24, 2007 at 06:23:45AM +0200, Nick Piggin wrote:
I'd just like to take the chance also to ask about a VM/FS meetup some
time around kernel summit (maybe take a big of time during UKUUG or so).
I won't be around until a day or two before KS, so
Chris Mason wrote:
On Mon, Jun 25, 2007 at 05:41:58PM +1000, Nick Piggin wrote:
Neil Brown wrote:
Why do you think you need PG_blocks?
Block device pagecache (buffer cache) has to be able to accept
attachment of either buffers or blocks for filesystem metadata,
and call into either
Hugh Dickins wrote:
On Mon, 25 Jun 2007, Petr Vandrovec wrote:
Hello,
to catch some memory corruption bug in our code I've modified malloc to do
mmap + mprotect - which has unfortunate effect that it creates thousands and
thousands of VMAs. Everything works (though rather slowly on kernel wit
Neil Brown wrote:
On Sunday June 24, [EMAIL PROTECTED] wrote:
+#define PG_blocks 20 /* Page has block mappings */
+
I've only had a very quick look, but this line looks *very* wrong.
You should be using PG_private.
There should never be any confusion about whether ->priva
Andi Kleen wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
[haven't read everything, just commenting on something that caught my eye]
+struct fsblock {
+ atomic_tcount;
+ union {
+ struct {
+ unsigned long flags; /* XXX:
Andi Kleen wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
- Structure packing. A page gets a number of buffer heads that are
allocated in a linked list. fsblocks are allocated contiguously, so
cacheline footprint is smaller in the above situation.
It would be interesting to test i
Chris Mason wrote:
On Sun, Jun 24, 2007 at 05:47:55AM +0200, Nick Piggin wrote:
My gut feeling is that there are several problem areas you haven't hit
yet, with the new code.
I would agree with your gut :)
Without having read the code yet (light reading for monday morning ;),
ext
Andrew Morton wrote:
On Tue, 19 Jun 2007 15:38:01 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
Ok and BUILD_BUG_ON really works? Had some bad experiences with it.
hm, I don't recall any problems, apart from its very obscure error
reporting.
But if it breaks, we get an opportuni
Paul Mundt wrote:
This adds preliminary NUMA support to SLOB, primarily aimed at systems
with small nodes (tested all the way down to a 128kB SRAM block), whether
asymmetric or otherwise.
Fine by me as well, FWIW. My points about per-cpu/node queues were not
to say that I'm really opposed to ge
I'd just like to take the chance also to ask about a VM/FS meetup some
time around kernel summit (maybe take a big of time during UKUUG or so).
I was thinking about trying to arrange a proper mini summit thing, but
it's a bit difficult and we could talk this year about doing it for
subsequent year
On Sat, Jun 23, 2007 at 11:07:54PM -0400, Jeff Garzik wrote:
> Nick Piggin wrote:
> >- No deadlocks (hopefully). The buffer layer is technically deadlocky by
> > design, because it can require memory allocations at page writeout-time.
> > It also has one path that c
Just clarify a few things. Don't you hate rereading a long work you
wrote? (oh, you're supposed to do that *before* you press send?).
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
>
> I'm announcing "fsblock" now because it is quite intrusive and so
Convert minix from buffer head to fsblock.
---
fs/minix/bitmap.c | 148 +--
fs/minix/file.c |6 -
fs/minix/inode.c| 172 ++--
fs/minix/itree_common.c | 227
f
Convert block_dev mostly to fsblocks.
---
fs/block_dev.c | 204 +++-
fs/buffer.c | 113 ++--
fs/super.c |2
include/linux/buffer_head.h |9 -
include/linux/fs.h | 29 ++
I'm announcing "fsblock" now because it is quite intrusive and so I'd
like to get some thoughts about significantly changing this core part
of the kernel.
fsblock is a rewrite of the "buffer layer" (ding dong the witch is
dead), which I have been working on, on and off and is now at the stage
whe
On Sat, Jun 16, 2007 at 07:39:17PM +0400, Dmitriy Monakhov wrote:
> Partial write can be easily supported by LO_CRYPT_NONE mode, but
> it is not easy in LO_CRYPT_CRYPTOAPI case, because of its block nature.
> I don't know who still used cryptoapi, but theoretically it is possible.
> So let's leave
Hi Adrian,
Thanks for doing these, but can we hold them off for now?
Thanks,
Nick
On Fri, Jun 15, 2007 at 12:15:45AM +0200, Adrian Bunk wrote:
> cont_expand_zero() can become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> --- linux-2.6.22-rc4-mm2/fs/buffer.c.old 200
On Fri, Jun 15, 2007 at 12:16:28AM +0200, Adrian Bunk wrote:
> This patch contains the following cleanups:
> - remove the following no longer used functions:
> - bitmap.c: reiserfs_claim_blocks_to_be_allocated()
> - bitmap.c: reiserfs_release_claimed_blocks()
> - bitmap.c: reiserfs_can_fit_pa
On Thu, Jun 14, 2007 at 11:52:49AM +0200, Jan Kara wrote:
> > On Wed, 2007-06-13 at 13:43 +0200, Nick Piggin wrote:
> > ..
> > >
> > > > 5) ext3_write_end:
> > > > Before write_begin/write_end patch set we have folowing locking
> > >
call_chain+0x2f/0x31
098eff60: [<08073f28>] panic+0x75/0x131
098eff84: [<080541d5>] init_post+0xcd/0xe8
098eff9c: [<08048ad4>] kernel_init+0x8e/0x9a
098effb4: [<08066dee>] run_kernel_thread+0x41/0x53
098effe0: [<08058e75>] new_thr
On Wed, Jun 13, 2007 at 04:07:01PM -0700, Badari Pulavarty wrote:
> On Wed, 2007-06-13 at 13:43 +0200, Nick Piggin wrote:
> ..
> >
> > > 5) ext3_write_end:
> > > Before write_begin/write_end patch set we have folowing locking
> > > ord
uff/added-to-mm.txt to find
> > out what to do about this
> >
> > --
> > Subject: fs: introduce write_begin, write_end, and perform_write aops
> > From: Nick Piggin <[EMAIL PROTECTED]>
> >
> > These are intended to replace prepare_write and com
Martin Steigerwald wrote:
Am Sonntag 10 Juni 2007 schrieb Linus Torvalds:
Hi Linus!
Ehh.. It was tested extensively by lots of people. It was in -mm for a
while, and yes, there have been tons of people testing both. I've
followed it, and it seems fair to say that yes, Ingo took a lot of
ideas
H. Peter Anvin wrote:
William Lee Irwin III wrote:
Robert P. J. Day wrote:
although it's not clear where in the source tree are the invocations
that would actually make a difference to a MIPS system, which is why
i've CC'ed ralf on this. i'm sure he can clear this up. :-)
On Thu, Jun 07, 2
Andrew Morton wrote:
On Sun, 10 Jun 2007 17:57:14 +0200 Eric Sesterhenn / Snakebyte <[EMAIL
PROTECTED]> wrote:
hi,
i got the following BUG while running the syscalls.sh
from ltp-full-20070531 on an ext3 partition, it is easily reproducible
for me
[ 476.338068] [ cut here ]-
Robert P. J. Day wrote:
probably making a fool of myself here, but what is the purpose of
that single argument to the macro "ZERO_PAGE"?
$ grep -r "define ZERO_PAGE" include
include/asm-frv/pgtable.h:#define ZERO_PAGE(vaddr) ({ BUG(); NULL; })
include/asm-frv/pgtable.h:#define ZERO_PAGE(v
Jared Hulbert wrote:
> The current xip stack relies on having struct page behind the memory
> segment. This causes few impact on memory management, but occupies some
> more memory. The cramfs patch chose to modify copy on write in order to
> deal with vmas that don't have struct page behind.
> So
On Thu, May 31, 2007 at 06:45:17PM -0700, Mark Fasheh wrote:
> On Fri, Jun 01, 2007 at 03:34:02AM +0200, Nick Piggin wrote:
> > > Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock the
> > > page, so long as it's returned in a locked state? Thou
On Thu, May 31, 2007 at 06:24:40PM -0700, Mark Fasheh wrote:
> On Fri, Jun 01, 2007 at 03:01:29AM +0200, Nick Piggin wrote:
> > Ah, I didn't realise you were using that yet. I expect ocfs2 is using
> > VM_CAN_INVALIDATE there anyway.
> >
> > Hmm, this b
On Thu, May 31, 2007 at 04:13:54PM -0700, Mark Fasheh wrote:
> On Wed, May 30, 2007 at 11:58:23PM -0700, Andrew Morton wrote:
> > git-ocfs2.patch
>
> Andrew, thanks for getting that back in there.
>
>
> mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch broke ocfs2 shared
> writable mmap
straight-line
bug, so it is probably the best way to go for now. I'd say
Acked-by: Nick Piggin <[EMAIL PROTECTED]>. Ram Pai I believe also worked on
similar issues with me, so I'll cc him.
Longer term, I have a few other issues with the fs layer returning non
uptodate pages to do_g
Neil Brown wrote:
[resending with correct To address - please reply to this one]
It appears that there is a race when reading from a file that is
concurrently being truncated. It is possible to read a number of
bytes that matches the size of the file before the truncate, but the
actual bytes ar
701 - 800 of 1974 matches
Mail list logo
