* opaque "pointer" API, model, best practice ? @ 2020-10-14 15:09 jim.cromie 2020-10-14 15:21 ` Greg KH 0 siblings, 1 reply; 3+ messages in thread From: jim.cromie @ 2020-10-14 15:09 UTC (permalink / raw) To: kernelnewbies hi all, is there an api / usage model / or best practice for opaque "handles" ? 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. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: opaque "pointer" API, model, best practice ? 2020-10-14 15:09 opaque "pointer" API, model, best practice ? jim.cromie @ 2020-10-14 15:21 ` Greg KH 2020-10-14 15:45 ` jim.cromie 0 siblings, 1 reply; 3+ messages in thread From: Greg KH @ 2020-10-14 15:21 UTC (permalink / raw) To: jim.cromie; +Cc: kernelnewbies 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: opaque "pointer" API, model, best practice ? 2020-10-14 15:21 ` Greg KH @ 2020-10-14 15:45 ` jim.cromie 0 siblings, 0 replies; 3+ messages in thread From: jim.cromie @ 2020-10-14 15:45 UTC (permalink / raw) To: Greg KH; +Cc: kernelnewbies 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-10-14 15:47 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-14 15:09 opaque "pointer" API, model, best practice ? jim.cromie 2020-10-14 15:21 ` Greg KH 2020-10-14 15:45 ` jim.cromie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).