Re: How to use a syscall in a module for 2.6.8 - header file problems

info_at_binarus.de
Date: 10/10/05

  • Next message: Peter T. Breuer: "Re: how to test driver" 
    Date: 10 Oct 2005 10:01:47 -0700

    Kasper Dupont wrote:
    > info@binarus.de wrote:
    > >
    > > Having said this, my problem is: I have to guarantee that _none_ of the
    > > memory used by this driver will ever be swapped out; this applies to
    > > the code itself, to the stack of the module and to any dynamically
    > > allocated memory.
    >
    > Kernel memory is never swapped out.
    >
    > > 1) I could not find a definition of what "kernel's code and data
    > > structures" exactly is. Can anybody give a definition?
    >
    > It is everything but user space.
    >
    > > 2) I think that memory which is allocated by kmalloc will be never
    > > swapped out to disk. Is this true?
    >
    > That is true.
    >
    > > 3) What about the stacks? Are stacks in kernel or module context
    > > guaranteed to never be swapped out (I suppose the answer will be also
    > > yes, but I have to be sure...)?
    >
    > Also true. The kernel simply wouldn't work if a kernel
    > stack was swapped out.
    >
    > > 4) Regarding swapping, is there any difference between "native" code
    > > which is compiled into the kernel itself and code which is added by
    > > insmoding a module? Same question not only for code, but also for
    > > stacks and kmalloc'ed data?
    > There are no differences regarding swapping. The code is put in
    > different parts of memory depending on whether it is compiled
    > into the kernel or as a module, but neither part can be swapped.
    > Stacks are associated with threads not with parts of the code,
    > and as such there is no difference. The same thread can execute
    > static kernel code at some times and module code at other times,
    > and most threads do. And as far as the memory manager is
    > concerned all slab allocations are the same no matter what part
    > of the kernel code allocated it, including kmalloc.

    O.K., thank your very much for these clear and explicit statements.
    This makes me feel much more comfortable :-)

    > What you have to worry about when allocating memory is, that the
    > alloc call itself may block. If you ask for memory, and there is
    > currently none free, then the process may block until memory has
    > been freed, which could involve disk access. Every allocation
    > call takes an argument with various flags, one of those flags
    > tell the allocator if such blocking can be accepted. If an
    > allocation is not allowed to block it is going to return an
    > error code instead.

    Yes, I've already read about this. These are the GFP_ Flags - no
    mystery so far.

    > What you also have to worry about is any access to user space,
    > which may block in case it has to be swapped in. If you need to
    > lock parts of user space in physical memory for example to do
    > DMA, then there exist ways to get a handle on single pages and
    > that way ensure they stay in physical memory. But I don't know
    > exactly how to do that.

    Currently, I don't need this, and until I need it, I hopefully have
    read some books about the kernel :-)

    > In most situations you will use copy_to_user and copy_from_user
    > to access user space. Notice that those two functions may block,
    > but as they are called from within a user process, only that
    > process is blocked. You don't have to worry about that when
    > writing kernel code. If it is a problem, then the user process
    > must call mlock (or mlockall).

    That was the thing what originally gave me the silly idea of using
    mlockall from within my module... But now I know better.

    > What you must also consider, is scheduling latencies and the
    > amount of time spend blocking on semaphores for whatever
    > reasons. Those latencies are not related to swapping, and
    > basically any part of the kernel spending too much time holding
    > any kind of locks could potentially increase the latency. This
    > may turn out to be much more troublesome than memory management.

    I think I can get around these pitfalls. I already had read about this
    subject for some hours, before posting my question, and I think have
    understood the important things... but the swapping thing was really
    not clear!

    O.K. then, once, again, many, many thanks for your valuable comments
    and your time.

    Peter

  • Next message: Peter T. Breuer: "Re: how to test driver"

    Relevant Pages

    • Re: Questions about Minix
      ... from the MMU to protect processes from messing up eachother's memory ... Paging is, but segmentation is not. ... in user mode and at kernel level if you need dynamic ... A Stack Fault to be handled in Ring 0 causes a stack switch (unless the ...
      (comp.os.minix)
    • Re: function "&" for strings type cause memory problem.
      ... > and I allocate the large object in heap memory in previous case. ... Memory allocation is always a risk. ... There is no difference between stack and heap here. ...
      (comp.lang.ada)
    • Re: Huge pages and small pages. . .
      ... Since the CPU uses virtual memory always, ... The actual allocation only occurs when an access happens. ... the kernel just marks a promised ... DMA operation occurs that crosses page boundaries. ...
      (Linux-Kernel)
    • Re: function "&" for strings type cause memory problem.
      ... > its execution state i. Si/|Si| is an average object size. ... >> and I allocate the large object in heap memory in previous case. ... One can ignore allocation issues as long as ... > the heap can be enlarged on demand while the stack not, ...
      (comp.lang.ada)
    • Re: ten thousand small processes
      ... them roughly in the middle you take space away from heap and stack ... identical across two processes as is the case with large shared memory ... There is no special allocation for virtual address space that is ... the standard libc or at least not the standard malloc implementation. ...
      (freebsd-performance)
    Loading