Kernel Newbies Archive on lore.kernel.org
 help / color / Atom feed
* 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, back to index

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

Kernel Newbies Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernelnewbies/0 kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ https://lore.kernel.org/kernelnewbies \
		kernelnewbies@kernelnewbies.org
	public-inbox-index kernelnewbies

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernelnewbies.kernelnewbies


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git