LWN: Comments on "Shared memory mappings for devices"

Shared memory mappings for devices

giraffedata — Tue, 15 May 2018 23:52:20 +0000

IBM used to do that in all its manuals as well, and it's an irritating style because acronyms are not abbreviations - they're words in their own right that are better known and have more meaning than the words from which they are derived. Sometimes the acquired meanings even contradict those words. The etymology of the acronym is still useful, of course, but the right way to do it is RAM (Random Access Memory), not Random Access Memory (RAM).

RAM is an interesting example, by the way, because words used illogically was another peeve Byte editors had and the magazine never used RAM to mean what most people meant by it: read/write memory. The term in Byte for that was "programmable memory." RAM would appear in Byte only in contrast with sequential access memory.

Shared memory mappings for devices

dezgeg — Mon, 14 May 2018 13:16:24 +0000

Maybe IDR could be made a backronym of say, "ID Registry" to hide the radix tree implementation detail.

Shared memory mappings for devices

cladisch — Fri, 11 May 2018 16:44:45 +0000

IDR is an ID allocator; the "R" stands for "radix tree", which is just an implementation detail.

IDA is an ID allocator that does not store a data poiner for each ID.

Shared memory mappings for devices

willy — Fri, 11 May 2018 14:16:47 +0000

Oh, I have no idea what either IDR or IDA stand for. It's not stated anywhere in the source code. I suppose I could search the mailing lists to find if there was any explanation when they were first published.

Shared memory mappings for devices

jem — Fri, 11 May 2018 07:37:52 +0000

Ironically, the documentation you linked to doesn't explain either what IDR or IDA are short for.

I miss Byte magazine, which meticulously spelled out an acronym the first time it appeared in an article, no matter how common. For example: "Random Access Memory (RAM)".

Shared memory mappings for devices

willy — Tue, 08 May 2018 21:33:58 +0000

https://www.kernel.org/doc/html/latest/core-api/idr.html

Shared memory mappings for devices

mirabilos — Tue, 08 May 2018 21:29:23 +0000

What’s an IDR?

Asking for my acronyms database…

Shared memory mappings for devices

Sesse — Tue, 08 May 2018 14:34:19 +0000

This isn't about this specific post, but it had to go somewhere: Thanks for the LFSMM coverage. Almost all the articles so far have been highly interesting.

Don't make this visible to userspace

ebiederm — Tue, 08 May 2018 02:39:23 +0000

This sounds like yet another darn global id that someone is going to make visible to userspace
and then it will need to get namespaced and then it's utility for device drivers will be gone.

So be very careful and don't even consider making something like this visible to userspace unless you intend to make it globally unique and even then hesitate and make absolutely certain that is what you want.

Shared memory mappings for devices

luto — Mon, 07 May 2018 21:37:17 +0000

Would it be u64? It’s quite important that it never gets reused.

Shared memory mappings for devices

spopuri — Mon, 07 May 2018 21:27:04 +0000

What is this for exactly? There have been other discussions about representing memory provided by an nvme drive with struct page structures. Is that the use-case? or is it more for things like HMM?

Shared memory mappings for devices

willy — Mon, 07 May 2018 21:02:14 +0000

I talked with Dave Hansen about ctx_id already. mm_id can replace it.

Shared memory mappings for devices

luto — Mon, 07 May 2018 20:42:45 +0000

On x86, we already have ctx_id. That could easily be moved to core code.

Shared memory mappings for devices

willy — Mon, 07 May 2018 20:31:33 +0000

Argh, I missed this session. Thanks for writing this up, Jake!

I have a preliminary patch to use an IDR to assign each mm_struct a u32 ID. There are various details around how quickly those can be reused. It actually saves memory (replacing the list_head with a u32). I'll try to get that finished up soon.