* Re: [Cocci] [PATCH v8] coccinelle: api: add kfree_mismatch script
@ 2020-10-16 9:46 Markus Elfring
2020-10-16 10:07 ` Julia Lawall
2020-10-18 16:00 ` [Cocci] Determination of an usage statistic for memory allocation calls Markus Elfring
0 siblings, 2 replies; 8+ messages in thread
From: Markus Elfring @ 2020-10-16 9:46 UTC (permalink / raw)
To: Denis Efremov, Coccinelle
Cc: Michal Marek, Gilles Muller, Nicolas Palix, kernel-janitors,
linux-kernel, Julia Lawall, Alexander Popov
…
> + E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\|
> + kmalloc_node\|kzalloc_node\|kmalloc_array\|
> + kmalloc_array_node\|kcalloc_node\)(...)@kok
…
How do you think about the possibility for any adjustments according to the order
of the mentioned function names in proposed disjunctions for the semantic patch language?
Can any additional identifiers become relevant?
Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Cocci] [PATCH v8] coccinelle: api: add kfree_mismatch script 2020-10-16 9:46 [Cocci] [PATCH v8] coccinelle: api: add kfree_mismatch script Markus Elfring @ 2020-10-16 10:07 ` Julia Lawall 2020-10-16 10:56 ` Markus Elfring 2020-10-18 16:00 ` [Cocci] Determination of an usage statistic for memory allocation calls Markus Elfring 1 sibling, 1 reply; 8+ messages in thread From: Julia Lawall @ 2020-10-16 10:07 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 999 bytes --] On Fri, 16 Oct 2020, Markus Elfring wrote: > … > > + E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\| > > + kmalloc_node\|kzalloc_node\|kmalloc_array\| > > + kmalloc_array_node\|kcalloc_node\)(...)@kok > … > > How do you think about the possibility for any adjustments according to the order > of the mentioned function names in proposed disjunctions for the semantic patch language? Please think about this for 5 seconds. Maybe there are 2000 calls to these allocation functions, and maybe there are a million function calls in the files that contain these calls. Microscopically optimizing the treatment of 2000 calls is not going to do anything to help the overall runtime, which depends on matching all of the above function names against the one million overall calls. > Can any additional identifiers become relevant? If you have other names to suggest, please do. If you don't have other names to suggest, then please stop asking such rhetorical questions. julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cocci] [PATCH v8] coccinelle: api: add kfree_mismatch script 2020-10-16 10:07 ` Julia Lawall @ 2020-10-16 10:56 ` Markus Elfring 0 siblings, 0 replies; 8+ messages in thread From: Markus Elfring @ 2020-10-16 10:56 UTC (permalink / raw) To: Julia Lawall, Denis Efremov, Coccinelle Cc: Michal Marek, Gilles Muller, Nicolas Palix, kernel-janitors, linux-kernel, Alexander Popov > > How do you think about the possibility for any adjustments according to the order > > of the mentioned function names in proposed disjunctions for the semantic patch language? > > Please think about this for 5 seconds. Maybe there are 2000 calls to > these allocation functions, and maybe there are a million function calls > in the files that contain these calls. Would you become interested to check the usage statistics in more detail? > Microscopically optimizing the treatment of 2000 calls is not going to do anything > to help the overall runtime, which depends on matching all > of the above function names against the one million overall calls. I got an other software understanding for the evaluation characteristics of discussed SmPL scripts. > > Can any additional identifiers become relevant? > > If you have other names to suggest, please do. If you don't have other > names to suggest, then please stop asking such rhetorical questions. I suggest to look at further possibilities so that more function call combinations can be checked automatically. How do you think about approaches to determine relevant properties in systematic ways (besides listing involved identifiers explicitly)? Regards, Markus _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cocci] Determination of an usage statistic for memory allocation calls 2020-10-16 9:46 [Cocci] [PATCH v8] coccinelle: api: add kfree_mismatch script Markus Elfring 2020-10-16 10:07 ` Julia Lawall @ 2020-10-18 16:00 ` Markus Elfring 2020-10-18 16:20 ` Julia Lawall 1 sibling, 1 reply; 8+ messages in thread From: Markus Elfring @ 2020-10-18 16:00 UTC (permalink / raw) To: Denis Efremov, Coccinelle Cc: Michal Marek, Gilles Muller, Nicolas Palix, kernel-janitors, linux-kernel, Julia Lawall, Alexander Popov > … > > + E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\| > > + kmalloc_node\|kzalloc_node\|kmalloc_array\| > > + kmalloc_array_node\|kcalloc_node\)(...)@kok > … > > How do you think about the possibility for any adjustments according to the order > of the mentioned function names in proposed disjunctions for the semantic patch language? I would like to share another source code analysis approach. I hope that this contribution can trigger further helpful software development ideas. @initialize:python@ @@ import sys def write_identifier(source, call): names = [] for x in source: names.append(call) sys.stdout.write("\n".join(names) + "\n") @find1@ expression e; identifier call, x; position pos; type rt; @@ rt x(...) { <+... e =@pos (kzalloc@call |kmalloc@call |kcalloc@call |kmalloc_array@call |kmemdup@call |kstrdup@call |vmalloc@call |vzalloc@call |kzalloc_node@call |kvmalloc@call |krealloc@call |kmalloc_node@call |kcalloc_node@call |__vmalloc@call |vmalloc_user@call |vzalloc_node@call |vmalloc_32@call |__vmalloc_node_range@call |vmalloc_node@call |kmalloc_array_node@call |__vmalloc_node@call |vmalloc_32_user@call |vmalloc_exec@call )(...) ...+> } @script:python collection1@ call << find1.call; place << find1.pos; @@ write_identifier(place, call) @find2@ identifier call, var, x; position pos; type rt, vt; @@ rt x(...) { <+... vt var =@pos (kzalloc@call |kmalloc@call |kcalloc@call |kmalloc_array@call |kmemdup@call |kstrdup@call |vmalloc@call |vzalloc@call |kzalloc_node@call |kvmalloc@call |krealloc@call |kmalloc_node@call |kcalloc_node@call |__vmalloc@call |vmalloc_user@call |vzalloc_node@call |vmalloc_32@call |__vmalloc_node_range@call |vmalloc_node@call |kmalloc_array_node@call |__vmalloc_node@call |vmalloc_32_user@call |vmalloc_exec@call )(...); ...+> } @script:python collection2@ call << find2.call; place << find2.pos; @@ write_identifier(place, call) Test result: elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20201016 && XX=$(date) && time spatch --timeout 23 --python python3 --jobs 4 --chunksize 1 --include-headers --no-includes --dir . ~/Projekte/Coccinelle/janitor/report_memory_allocation_calls4.cocci 2> ~/Projekte/Bau/Linux/scripts/Coccinelle/call_checks/20201016/report_memory_allocation_calls4-errors.txt | echo "$(echo 'call' && cat)" | csvsql --query 'select call, count(*) from stdin group by call order by count(*) desc'; YY=$(date) && echo "$XX | $YY" … call,count(*) kzalloc,12652 kmalloc,4902 kcalloc,2564 kmalloc_array,859 kmemdup,797 kstrdup,469 vmalloc,405 vzalloc,359 kzalloc_node,177 kvmalloc,154 krealloc,151 kmalloc_node,49 kcalloc_node,44 __vmalloc,34 vmalloc_user,28 vzalloc_node,21 vmalloc_32,9 __vmalloc_node_range,8 vmalloc_node,7 kmalloc_array_node,5 __vmalloc_node,4 vmalloc_32_user,1 real 22m25,049s user 84m11,257s sys 0m12,168s So 18. Okt 16:55:08 CEST 2020 | So 18. Okt 17:17:33 CEST 2020 The log file contains the information “9211 files match”. Can such facts influence the specification of efficient SmPL disjunctions another bit? Regards, Markus _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cocci] Determination of an usage statistic for memory allocation calls 2020-10-18 16:00 ` [Cocci] Determination of an usage statistic for memory allocation calls Markus Elfring 2020-10-18 16:20 ` Julia Lawall @ 2020-10-18 16:20 ` Julia Lawall 0 siblings, 0 replies; 8+ messages in thread From: Julia Lawall @ 2020-10-18 16:20 UTC (permalink / raw) To: Markus Elfring Cc: Michal Marek, Gilles Muller, Nicolas Palix, kernel-janitors, linux-kernel, Coccinelle, Alexander Popov [-- Attachment #1: Type: text/plain, Size: 3601 bytes --] On Sun, 18 Oct 2020, Markus Elfring wrote: > > … > > > + E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\| > > > + kmalloc_node\|kzalloc_node\|kmalloc_array\| > > > + kmalloc_array_node\|kcalloc_node\)(...)@kok > > … > > > > How do you think about the possibility for any adjustments according to the order > > of the mentioned function names in proposed disjunctions for the semantic patch language? > > > I would like to share another source code analysis approach. > I hope that this contribution can trigger further helpful software development ideas. > > > @initialize:python@ > @@ > import sys > > def write_identifier(source, call): > names = [] > for x in source: > names.append(call) > > sys.stdout.write("\n".join(names) + "\n") > > @find1@ > expression e; > identifier call, x; > position pos; > type rt; > @@ > rt x(...) > { > <+... > e =@pos > (kzalloc@call > |kmalloc@call > |kcalloc@call > |kmalloc_array@call > |kmemdup@call > |kstrdup@call > |vmalloc@call > |vzalloc@call > |kzalloc_node@call > |kvmalloc@call > |krealloc@call > |kmalloc_node@call > |kcalloc_node@call > |__vmalloc@call > |vmalloc_user@call > |vzalloc_node@call > |vmalloc_32@call > |__vmalloc_node_range@call > |vmalloc_node@call > |kmalloc_array_node@call > |__vmalloc_node@call > |vmalloc_32_user@call > |vmalloc_exec@call > )(...) > ...+> > } > > @script:python collection1@ > call << find1.call; > place << find1.pos; > @@ > write_identifier(place, call) > > @find2@ > identifier call, var, x; > position pos; > type rt, vt; > @@ > rt x(...) > { > <+... > vt var =@pos > (kzalloc@call > |kmalloc@call > |kcalloc@call > |kmalloc_array@call > |kmemdup@call > |kstrdup@call > |vmalloc@call > |vzalloc@call > |kzalloc_node@call > |kvmalloc@call > |krealloc@call > |kmalloc_node@call > |kcalloc_node@call > |__vmalloc@call > |vmalloc_user@call > |vzalloc_node@call > |vmalloc_32@call > |__vmalloc_node_range@call > |vmalloc_node@call > |kmalloc_array_node@call > |__vmalloc_node@call > |vmalloc_32_user@call > |vmalloc_exec@call > )(...); > ...+> > } > > @script:python collection2@ > call << find2.call; > place << find2.pos; > @@ > write_identifier(place, call) > > > Test result: > elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20201016 && XX=$(date) && time spatch --timeout 23 --python python3 --jobs 4 --chunksize 1 --include-headers --no-includes --dir . ~/Projekte/Coccinelle/janitor/report_memory_allocation_calls4.cocci 2> ~/Projekte/Bau/Linux/scripts/Coccinelle/call_checks/20201016/report_memory_allocation_calls4-errors.txt | echo "$(echo 'call' && cat)" | csvsql --query 'select call, count(*) from stdin group by call order by count(*) desc'; YY=$(date) && echo "$XX | $YY" > … > call,count(*) > kzalloc,12652 > kmalloc,4902 > kcalloc,2564 > kmalloc_array,859 > kmemdup,797 > kstrdup,469 > vmalloc,405 > vzalloc,359 > kzalloc_node,177 > kvmalloc,154 > krealloc,151 > kmalloc_node,49 > kcalloc_node,44 > __vmalloc,34 > vmalloc_user,28 > vzalloc_node,21 > vmalloc_32,9 > __vmalloc_node_range,8 > vmalloc_node,7 > kmalloc_array_node,5 > __vmalloc_node,4 > vmalloc_32_user,1 > > real 22m25,049s > user 84m11,257s > sys 0m12,168s > So 18. Okt 16:55:08 CEST 2020 | So 18. Okt 17:17:33 CEST 2020 > > > The log file contains the information “9211 files match”. > Can such facts influence the specification of efficient SmPL disjunctions another bit? On my machine, putting the three functions that you have foudn to be the most frequent at the end of each disjunction has no impact on the performance. So what do you suggest? julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cocci] Determination of an usage statistic for memory allocation calls @ 2020-10-18 16:20 ` Julia Lawall 0 siblings, 0 replies; 8+ messages in thread From: Julia Lawall @ 2020-10-18 16:20 UTC (permalink / raw) To: Markus Elfring Cc: Denis Efremov, Coccinelle, Michal Marek, Gilles Muller, Nicolas Palix, kernel-janitors, linux-kernel, Alexander Popov [-- Attachment #1: Type: text/plain, Size: 3601 bytes --] On Sun, 18 Oct 2020, Markus Elfring wrote: > > … > > > + E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\| > > > + kmalloc_node\|kzalloc_node\|kmalloc_array\| > > > + kmalloc_array_node\|kcalloc_node\)(...)@kok > > … > > > > How do you think about the possibility for any adjustments according to the order > > of the mentioned function names in proposed disjunctions for the semantic patch language? > > > I would like to share another source code analysis approach. > I hope that this contribution can trigger further helpful software development ideas. > > > @initialize:python@ > @@ > import sys > > def write_identifier(source, call): > names = [] > for x in source: > names.append(call) > > sys.stdout.write("\n".join(names) + "\n") > > @find1@ > expression e; > identifier call, x; > position pos; > type rt; > @@ > rt x(...) > { > <+... > e =@pos > (kzalloc@call > |kmalloc@call > |kcalloc@call > |kmalloc_array@call > |kmemdup@call > |kstrdup@call > |vmalloc@call > |vzalloc@call > |kzalloc_node@call > |kvmalloc@call > |krealloc@call > |kmalloc_node@call > |kcalloc_node@call > |__vmalloc@call > |vmalloc_user@call > |vzalloc_node@call > |vmalloc_32@call > |__vmalloc_node_range@call > |vmalloc_node@call > |kmalloc_array_node@call > |__vmalloc_node@call > |vmalloc_32_user@call > |vmalloc_exec@call > )(...) > ...+> > } > > @script:python collection1@ > call << find1.call; > place << find1.pos; > @@ > write_identifier(place, call) > > @find2@ > identifier call, var, x; > position pos; > type rt, vt; > @@ > rt x(...) > { > <+... > vt var =@pos > (kzalloc@call > |kmalloc@call > |kcalloc@call > |kmalloc_array@call > |kmemdup@call > |kstrdup@call > |vmalloc@call > |vzalloc@call > |kzalloc_node@call > |kvmalloc@call > |krealloc@call > |kmalloc_node@call > |kcalloc_node@call > |__vmalloc@call > |vmalloc_user@call > |vzalloc_node@call > |vmalloc_32@call > |__vmalloc_node_range@call > |vmalloc_node@call > |kmalloc_array_node@call > |__vmalloc_node@call > |vmalloc_32_user@call > |vmalloc_exec@call > )(...); > ...+> > } > > @script:python collection2@ > call << find2.call; > place << find2.pos; > @@ > write_identifier(place, call) > > > Test result: > elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20201016 && XX=$(date) && time spatch --timeout 23 --python python3 --jobs 4 --chunksize 1 --include-headers --no-includes --dir . ~/Projekte/Coccinelle/janitor/report_memory_allocation_calls4.cocci 2> ~/Projekte/Bau/Linux/scripts/Coccinelle/call_checks/20201016/report_memory_allocation_calls4-errors.txt | echo "$(echo 'call' && cat)" | csvsql --query 'select call, count(*) from stdin group by call order by count(*) desc'; YY=$(date) && echo "$XX | $YY" > … > call,count(*) > kzalloc,12652 > kmalloc,4902 > kcalloc,2564 > kmalloc_array,859 > kmemdup,797 > kstrdup,469 > vmalloc,405 > vzalloc,359 > kzalloc_node,177 > kvmalloc,154 > krealloc,151 > kmalloc_node,49 > kcalloc_node,44 > __vmalloc,34 > vmalloc_user,28 > vzalloc_node,21 > vmalloc_32,9 > __vmalloc_node_range,8 > vmalloc_node,7 > kmalloc_array_node,5 > __vmalloc_node,4 > vmalloc_32_user,1 > > real 22m25,049s > user 84m11,257s > sys 0m12,168s > So 18. Okt 16:55:08 CEST 2020 | So 18. Okt 17:17:33 CEST 2020 > > > The log file contains the information “9211 files match”. > Can such facts influence the specification of efficient SmPL disjunctions another bit? On my machine, putting the three functions that you have foudn to be the most frequent at the end of each disjunction has no impact on the performance. So what do you suggest? julia ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cocci] Determination of an usage statistic for memory allocation calls @ 2020-10-18 16:20 ` Julia Lawall 0 siblings, 0 replies; 8+ messages in thread From: Julia Lawall @ 2020-10-18 16:20 UTC (permalink / raw) To: Markus Elfring Cc: Michal Marek, Gilles Muller, Nicolas Palix, kernel-janitors, linux-kernel, Coccinelle, Alexander Popov [-- Attachment #1: Type: text/plain, Size: 3601 bytes --] On Sun, 18 Oct 2020, Markus Elfring wrote: > > … > > > + E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\| > > > + kmalloc_node\|kzalloc_node\|kmalloc_array\| > > > + kmalloc_array_node\|kcalloc_node\)(...)@kok > > … > > > > How do you think about the possibility for any adjustments according to the order > > of the mentioned function names in proposed disjunctions for the semantic patch language? > > > I would like to share another source code analysis approach. > I hope that this contribution can trigger further helpful software development ideas. > > > @initialize:python@ > @@ > import sys > > def write_identifier(source, call): > names = [] > for x in source: > names.append(call) > > sys.stdout.write("\n".join(names) + "\n") > > @find1@ > expression e; > identifier call, x; > position pos; > type rt; > @@ > rt x(...) > { > <+... > e =@pos > (kzalloc@call > |kmalloc@call > |kcalloc@call > |kmalloc_array@call > |kmemdup@call > |kstrdup@call > |vmalloc@call > |vzalloc@call > |kzalloc_node@call > |kvmalloc@call > |krealloc@call > |kmalloc_node@call > |kcalloc_node@call > |__vmalloc@call > |vmalloc_user@call > |vzalloc_node@call > |vmalloc_32@call > |__vmalloc_node_range@call > |vmalloc_node@call > |kmalloc_array_node@call > |__vmalloc_node@call > |vmalloc_32_user@call > |vmalloc_exec@call > )(...) > ...+> > } > > @script:python collection1@ > call << find1.call; > place << find1.pos; > @@ > write_identifier(place, call) > > @find2@ > identifier call, var, x; > position pos; > type rt, vt; > @@ > rt x(...) > { > <+... > vt var =@pos > (kzalloc@call > |kmalloc@call > |kcalloc@call > |kmalloc_array@call > |kmemdup@call > |kstrdup@call > |vmalloc@call > |vzalloc@call > |kzalloc_node@call > |kvmalloc@call > |krealloc@call > |kmalloc_node@call > |kcalloc_node@call > |__vmalloc@call > |vmalloc_user@call > |vzalloc_node@call > |vmalloc_32@call > |__vmalloc_node_range@call > |vmalloc_node@call > |kmalloc_array_node@call > |__vmalloc_node@call > |vmalloc_32_user@call > |vmalloc_exec@call > )(...); > ...+> > } > > @script:python collection2@ > call << find2.call; > place << find2.pos; > @@ > write_identifier(place, call) > > > Test result: > elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20201016 && XX=$(date) && time spatch --timeout 23 --python python3 --jobs 4 --chunksize 1 --include-headers --no-includes --dir . ~/Projekte/Coccinelle/janitor/report_memory_allocation_calls4.cocci 2> ~/Projekte/Bau/Linux/scripts/Coccinelle/call_checks/20201016/report_memory_allocation_calls4-errors.txt | echo "$(echo 'call' && cat)" | csvsql --query 'select call, count(*) from stdin group by call order by count(*) desc'; YY=$(date) && echo "$XX | $YY" > … > call,count(*) > kzalloc,12652 > kmalloc,4902 > kcalloc,2564 > kmalloc_array,859 > kmemdup,797 > kstrdup,469 > vmalloc,405 > vzalloc,359 > kzalloc_node,177 > kvmalloc,154 > krealloc,151 > kmalloc_node,49 > kcalloc_node,44 > __vmalloc,34 > vmalloc_user,28 > vzalloc_node,21 > vmalloc_32,9 > __vmalloc_node_range,8 > vmalloc_node,7 > kmalloc_array_node,5 > __vmalloc_node,4 > vmalloc_32_user,1 > > real 22m25,049s > user 84m11,257s > sys 0m12,168s > So 18. Okt 16:55:08 CEST 2020 | So 18. Okt 17:17:33 CEST 2020 > > > The log file contains the information “9211 files match”. > Can such facts influence the specification of efficient SmPL disjunctions another bit? On my machine, putting the three functions that you have foudn to be the most frequent at the end of each disjunction has no impact on the performance. So what do you suggest? julia ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Cocci] Determination of an usage statistic for memory allocation calls 2020-10-18 16:20 ` Julia Lawall (?) (?) @ 2020-10-18 16:46 ` Markus Elfring -1 siblings, 0 replies; 8+ messages in thread From: Markus Elfring @ 2020-10-18 16:46 UTC (permalink / raw) To: Julia Lawall, Denis Efremov, Coccinelle Cc: Michal Marek, Gilles Muller, Nicolas Palix, kernel-janitors, linux-kernel, Alexander Popov > > Can such facts influence the specification of efficient SmPL disjunctions another bit? > > On my machine, putting the three functions that you have foudn to be the > most frequent at the end of each disjunction has no impact on the performance. I propose to reconsider this view. > So what do you suggest? 1. I would appreciate if you would share more technical details about your test environment for a safer comparison. 2. The observed software behaviour can be clarified further, can't it? Aspects like the following can trigger corresponding development considerations. * “noticable” differences (depending on the run time environment) * measurable effects * mathematical properties of an algorithm Regards, Markus _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-10-18 20:15 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-10-16 9:46 [Cocci] [PATCH v8] coccinelle: api: add kfree_mismatch script Markus Elfring 2020-10-16 10:07 ` Julia Lawall 2020-10-16 10:56 ` Markus Elfring 2020-10-18 16:00 ` [Cocci] Determination of an usage statistic for memory allocation calls Markus Elfring 2020-10-18 16:20 ` Julia Lawall 2020-10-18 16:20 ` Julia Lawall 2020-10-18 16:20 ` Julia Lawall 2020-10-18 16:46 ` Markus Elfring
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.