On Thu, 22 Feb 2007, Pekka Enberg wrote:
> I think we can merge krealloc without unionfs. I'll whoop up a new patch as
> per Christoph's suggestions. I think at least XFS already has its own realloc
> and there might be some other open-coded users. It's not _changing_ the slab
> as much as adding
On Thu, Feb 22, 2007 at 08:18:39AM +0200, Pekka Enberg wrote:
> Pekka Enberg wrote:
> >The ksize exports we can add later if unionfs is to be merged.
>
> Actually, we probably don't need it after the krealloc optimizations. I
> think we need a new unionfs patch too... :)
I'm for it!
Josef "Je
Pekka Enberg wrote:
The ksize exports we can add later if unionfs is to be merged.
Actually, we probably don't need it after the krealloc optimizations. I
think we need a new unionfs patch too... :)
Pekka
-
To unsubscribe from this list: send the line "unsubsc
Hi Andrew,
Andrew Morton wrote:
Problem is, it doesn't seem that we'll be merging unionfs any time soon so
we shouldn't be adding slab infrastructure on its behalf. And I'd prefer
not to have to carry slab changes in a filesystem tree.
I think we can merge krealloc without unionfs. I'll whoop
On Wed, Feb 21, 2007 at 06:26:57PM -0800, Andrew Morton wrote:
> On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek <[EMAIL PROTECTED]> wrote:
>
> > > I can't say more until I've managed to understand your description, which
> > > might take a while.
> >
> > It is intended for reallocation of a buffe
For what it's worth, the new branch-management code also needs realloc():
right now I do a kfree/kalloc instead. So I'm all for having a true
krealloc function.
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More major
On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek <[EMAIL PROTECTED]> wrote:
> > I can't say more until I've managed to understand your description, which
> > might take a while.
>
> It is intended for reallocation of a buffer. The code in lookup.c allocates
> some memory, and it may have to realloc
On Wed, Feb 21, 2007 at 02:19:44PM -0800, Andrew Morton wrote:
> On Tue, 20 Feb 2007 10:13:56 -0500
> Josef Sipek <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
> > > On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > > CC fs/unionfs/copy
On Tue, 20 Feb 2007 10:13:56 -0500
Josef Sipek <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
> > On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > CC fs/unionfs/copyup.o
> > >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:
For the time being, I included it in unionfs.git. I wouldn't mind having
this dependency disappear.
Thanks,
Josef "Jeff" Sipek.
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Josef Sipek:
> That's the only user of malloc_sizes. It is supposed to be an optimization -
> we get the smallest sized piece of memory even if we don't need all of it.
> This way we don't reallocate & memcpy needlessly.
How about exporting ksize to modules, and introduce a new function such
like
On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
> On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > CC fs/unionfs/copyup.o
> >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c: In
> >function 'create_parents_named':
> >/home/bunk/linux/kernel-2.6/linux-2.6.2
On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
CC fs/unionfs/copyup.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c: In function
'create_parents_named':
/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620: error:
'malloc_sizes' undeclared (first us
On Sat, Feb 17, 2007 at 09:51:46PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-mm1:
>...
> git-unionfs.patch
>...
> git trees
>...
<-- snip -->
...
CC fs/unionfs/copyup.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c: In function
'create_parents_named':
14 matches
Mail list logo