Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-09-09 at 15:02 +0300, Pekka J Enberg wrote:
> > On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
> > > > I completely disagree with you given that this is not "inventing
> > > > [...] own memory allocators", it is just a convenient short
On Fri, 2005-09-09 at 15:53 +0100, Christoph Hellwig wrote:
> On Fri, Sep 09, 2005 at 07:51:23AM -0700, Roland Dreier wrote:
> > Anton> fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc()
> > Anton> based allocations with __GFP_HIGHMEM, analogous to how the
> > Anton> vmalloc()
On Fri, Sep 09, 2005 at 07:51:23AM -0700, Roland Dreier wrote:
> Anton> fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc()
> Anton> based allocations with __GFP_HIGHMEM, analogous to how the
> Anton> vmalloc() based allocations are done.
>
> Does it make sense to pass
Anton> fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc()
Anton> based allocations with __GFP_HIGHMEM, analogous to how the
Anton> vmalloc() based allocations are done.
Does it make sense to pass __GFP_HIGHMEM to kmalloc()? kmalloc() has
to return memory from lowmem, since it
On Fri, 2005-09-09 at 15:02 +0300, Pekka J Enberg wrote:
> On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
> > > I completely disagree with you given that this is not "inventing [...]
> > > own memory allocators", it is just a convenient short hand. I am sure a
> > > lot of people would agree with
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
> > I completely disagree with you given that this is not "inventing [...]
> > own memory allocators", it is just a convenient short hand. I am sure a
> > lot of people would agree with you though. It is just a matter of
> > personal preference.
>
>
On Fri, 2005-09-09 at 12:48 +0100, Anton Altaparmakov wrote:
> On Fri, 2005-09-09 at 14:38 +0300, Pekka J Enberg wrote:
> > On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
> > > They could be but I would rather not. What if one day I decide to
> > > change how ntfs_malloc_nofs() works? Then it
On Fri, 2005-09-09 at 14:38 +0300, Pekka J Enberg wrote:
> On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
> > They could be but I would rather not. What if one day I decide to
> > change how ntfs_malloc_nofs() works? Then it would be needed to
> > carefully go through the whole driver looking
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
> They could be but I would rather not. What if one day I decide to
> change how ntfs_malloc_nofs() works? Then it would be needed to
> carefully go through the whole driver looking for places where kmalloc
> is used and change those, too.
>
> From
On Fri, 2005-09-09 at 14:15 +0300, Pekka J Enberg wrote:
> On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
> > Also note I only use the ntfs_malloc_nofs() wrapper if I have to. If I
> > know how much I am allocating or at least know that the maximum is quite
> > small, I use kmalloc() directly. It
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
> Also note I only use the ntfs_malloc_nofs() wrapper if I have to. If I
> know how much I am allocating or at least know that the maximum is quite
> small, I use kmalloc() directly. It is pretty much only for the runlist
> allocations that I use the
On Fri, 2005-09-09 at 13:36 +0300, Pekka Enberg wrote:
> On 9/9/05, Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> > -static inline void *ntfs_malloc_nofs(unsigned long size)
> > +static inline void *__ntfs_malloc(unsigned long size,
> > + unsigned int __nocast gfp_mask)
> > {
> >
On 9/9/05, Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> -static inline void *ntfs_malloc_nofs(unsigned long size)
> +static inline void *__ntfs_malloc(unsigned long size,
> + unsigned int __nocast gfp_mask)
> {
> if (likely(size <= PAGE_SIZE)) {
>
NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version.
- Modify fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc() based
allocations with __GFP_HIGHMEM, analogous to how the vmalloc() based
allocations are done.
- Add fs/ntfs/malloc.h::ntfs_malloc_nofs_nofail()
NTFS: Allow highmem kmalloc() in ntfs_malloc_nofs() and add _nofail() version.
- Modify fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc() based
allocations with __GFP_HIGHMEM, analogous to how the vmalloc() based
allocations are done.
- Add fs/ntfs/malloc.h::ntfs_malloc_nofs_nofail()
On 9/9/05, Anton Altaparmakov [EMAIL PROTECTED] wrote:
-static inline void *ntfs_malloc_nofs(unsigned long size)
+static inline void *__ntfs_malloc(unsigned long size,
+ unsigned int __nocast gfp_mask)
{
if (likely(size = PAGE_SIZE)) {
BUG_ON(!size);
On Fri, 2005-09-09 at 13:36 +0300, Pekka Enberg wrote:
On 9/9/05, Anton Altaparmakov [EMAIL PROTECTED] wrote:
-static inline void *ntfs_malloc_nofs(unsigned long size)
+static inline void *__ntfs_malloc(unsigned long size,
+ unsigned int __nocast gfp_mask)
{
if
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
Also note I only use the ntfs_malloc_nofs() wrapper if I have to. If I
know how much I am allocating or at least know that the maximum is quite
small, I use kmalloc() directly. It is pretty much only for the runlist
allocations that I use the
On Fri, 2005-09-09 at 14:15 +0300, Pekka J Enberg wrote:
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
Also note I only use the ntfs_malloc_nofs() wrapper if I have to. If I
know how much I am allocating or at least know that the maximum is quite
small, I use kmalloc() directly. It is
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
They could be but I would rather not. What if one day I decide to
change how ntfs_malloc_nofs() works? Then it would be needed to
carefully go through the whole driver looking for places where kmalloc
is used and change those, too.
From a
On Fri, 2005-09-09 at 14:38 +0300, Pekka J Enberg wrote:
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
They could be but I would rather not. What if one day I decide to
change how ntfs_malloc_nofs() works? Then it would be needed to
carefully go through the whole driver looking for
On Fri, 2005-09-09 at 12:48 +0100, Anton Altaparmakov wrote:
On Fri, 2005-09-09 at 14:38 +0300, Pekka J Enberg wrote:
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
They could be but I would rather not. What if one day I decide to
change how ntfs_malloc_nofs() works? Then it would be
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
I completely disagree with you given that this is not inventing [...]
own memory allocators, it is just a convenient short hand. I am sure a
lot of people would agree with you though. It is just a matter of
personal preference.
I should
On Fri, 2005-09-09 at 15:02 +0300, Pekka J Enberg wrote:
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
I completely disagree with you given that this is not inventing [...]
own memory allocators, it is just a convenient short hand. I am sure a
lot of people would agree with you though.
Anton fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc()
Anton based allocations with __GFP_HIGHMEM, analogous to how the
Anton vmalloc() based allocations are done.
Does it make sense to pass __GFP_HIGHMEM to kmalloc()? kmalloc() has
to return memory from lowmem, since it
On Fri, Sep 09, 2005 at 07:51:23AM -0700, Roland Dreier wrote:
Anton fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc()
Anton based allocations with __GFP_HIGHMEM, analogous to how the
Anton vmalloc() based allocations are done.
Does it make sense to pass __GFP_HIGHMEM to
On Fri, 2005-09-09 at 15:53 +0100, Christoph Hellwig wrote:
On Fri, Sep 09, 2005 at 07:51:23AM -0700, Roland Dreier wrote:
Anton fs/ntfs/malloc.h::ntfs_malloc_nofs() to do the kmalloc()
Anton based allocations with __GFP_HIGHMEM, analogous to how the
Anton vmalloc() based
Anton Altaparmakov [EMAIL PROTECTED] wrote:
On Fri, 2005-09-09 at 15:02 +0300, Pekka J Enberg wrote:
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
I completely disagree with you given that this is not inventing
[...] own memory allocators, it is just a convenient short hand.
I am
28 matches
Mail list logo
