[lkml]   [2007]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
    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 far, Hugh and Linus have shown strong opposition against copy on
    >> > write with no struct page behind. If this implementation is acceptable
    >> > to the them, it seems preferable to me over wasting memory. The xip
    >> > stack should be modified to use this vma flag in that case.
    >> I would rather not :P
    >> We can copy on write without a struct page behind the source today, no?
    > The existing COW techniques fail on some corner cases. I'm not up to
    > speed on the vm code. I'll try to look into this a little more but it
    > might be useful if I knew what questions I need to answer so you vm
    > experts can understand the problem.

    Previously I believe we couldn't do COW without a struct page for the
    source memory, nor could we COW with a source that is not readable
    from the kernel virtual mapping.

    Now we can do both. cow_user_page in mm/memory.c does a copy_from_user
    if there is no source page, so it uses the user mappings and does not
    require a struct page.

    The question is, why is that not enough (I haven't looked at these
    patches enough to work out if there is anything more they provide).

    > Let me give one example. If you try to debug an XIP application
    > without this patch, bad things happen. XIP in this sense is synomous
    > with executing directly out of Flash and you can't just change the
    > physical memory to redirect it to the debugger so easily in Flash.
    > Now I don't know exactly why yet some, but not all applications,
    > trigger this added vm hack. I'm not sure exactly why it would get
    > triggered under normal circumstances. Why would a read-only map get
    > written to?
    >> What is insufficient for the XIP code with the current COW?
    > So I think the problem may have something to do with the nature of the
    > memory in question. We are using Flash that is ioremap()'ed to a
    > usable virtual address. And yet we go on to try to use it as if it
    > were plain old system memory, like any RAM page. We need it to be
    > presented as any other memory page only physically read-only.
    > ioremap() seems to be a hacky way of accomplishing that, but I can't
    > think of better way. In ARM we even had to invent ioremap_cached() to
    > improve performance. Thoughts?

    SUSE Labs, Novell Inc.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-02 10:45    [W:0.024 / U:42.444 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site