15 Apr, 2016

1 commit

  • __GFP_REPEAT has a rather weak semantic but since it has been introduced
    around 2.6.12 it has been ignored for low order allocations.

    lzo_init uses __GFP_REPEAT to allocate LZO1X_MEM_COMPRESS 16K. This is
    order 3 allocation request and __GFP_REPEAT is ignored for this size
    as well as all
    Cc: "David S. Miller"
    Cc: linux-crypto@vger.kernel.org
    Signed-off-by: Michal Hocko
    Signed-off-by: Herbert Xu

    Michal Hocko
     

24 Nov, 2014

1 commit


25 Jun, 2014

1 commit


20 Jun, 2014

1 commit

  • zswap allocates one LZO context per online cpu.

    Using vmalloc() for small (16KB) memory areas has drawback of slowing
    down /proc/vmallocinfo and /proc/meminfo reads, TLB pressure and poor
    NUMA locality, as default NUMA policy at boot time is to interleave
    pages :

    edumazet:~# grep lzo /proc/vmallocinfo | head -4
    0xffffc90006062000-0xffffc90006067000 20480 lzo_init+0x1b/0x30 pages=4 vmalloc N0=2 N1=2
    0xffffc90006067000-0xffffc9000606c000 20480 lzo_init+0x1b/0x30 pages=4 vmalloc N0=2 N1=2
    0xffffc9000606c000-0xffffc90006071000 20480 lzo_init+0x1b/0x30 pages=4 vmalloc N0=2 N1=2
    0xffffc90006071000-0xffffc90006076000 20480 lzo_init+0x1b/0x30 pages=4 vmalloc N0=2 N1=2

    This patch tries a regular kmalloc() and fallback to vmalloc in case
    memory is too fragmented.

    Signed-off-by: Eric Dumazet
    Signed-off-by: Herbert Xu

    Eric Dumazet
     

01 Aug, 2012

1 commit

  • Initialization of cra_list is currently mixed, most ciphers initialize this
    field and most shashes do not. Initialization however is not needed at all
    since cra_list is initialized/overwritten in __crypto_register_alg() with
    list_add(). Therefore perform cleanup to remove all unneeded initializations
    of this field in 'crypto/'.

    Signed-off-by: Jussi Kivilinna
    Signed-off-by: Herbert Xu

    Jussi Kivilinna
     

21 Apr, 2008

1 commit

  • On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote:
    > Kamalesh Babulal wrote:
    >
    > > This patch cleanups the crypto code, replaces the init() and fini()
    > > with the _init/_fini
    >
    > This part ist OK.
    >
    > > or init/fini_ (if the
    > > _init/_fini exist)
    >
    > Having init_foo and foo_init won't be a good thing, will it? I'd start
    > confusing them.
    >
    > What about foo_modinit instead?

    Thanks for the suggestion, the init() is replaced with

    _mod_init ()

    and fini () is replaced with _mod_fini.

    Signed-off-by: Kamalesh Babulal
    Signed-off-by: Herbert Xu

    Kamalesh Babulal
     

11 Jan, 2008

1 commit