On Wed, Oct 14, 2020 at 9:21 AM Greg KH <greg@kroah.com> wrote:
On Wed, Oct 14, 2020 at 09:09:11AM -0600, jim.cromie@gmail.com wrote:
hi all,
is there an api / usage model / or best practice for opaque "handles" ?
"it depends" :)
What are you wanting to do exactly?
Im aware of 1 case: the handle returned by zs_malloc I have tried to use it, and have run into locking conflicts when trying to keep the memory zs_mapped longer than the duration of a function. OTOH, if I map and unmap within the function, things work, but this is unacceptable overhead.
so I figure I should read some good code, rather than keep hacking at bad code.
Again, what are you trying to do?
greg k-h
Im trying to put dynamic-debug metadata on a diet. Ive split struct _ddebug into 2 (new part is struct -_ddebug_callsite) with a pointer linking them (intialied by DECLARE_DYNAMIC_DEUG_METADAT) The _callsite records have lots of redundancy in module, file, function pointers, so Im hoping rzram can compress that all away. Ive managed to zs_malloc and copy the _callsite recs, and to zs_map them in when executing pr_debug (and thereby ddebug_emit_prefix) as long as I unmap immediately afterwards. But if I try to keep the mapping for the next potential print, things blow up, with a lot of lockdep complaints and a panic. If I can make it work, we can retire the new section I created for the _callsite data, and reduce the ~160kb of table storage by 30% Ive been meaning to send it to mm-linux, but havent yet de-cluttered it enough