EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS Base Release-Candidate Double Feature!
From: Andrew Johnson <[email protected]>
To: bob dalesio <[email protected]>, EPICS core-talk <[email protected]>
Date: Thu, 3 Nov 2016 12:54:13 -0500
Hi Bob,

On 11/03/2016 11:16 AM, bob dalesio wrote:
> We should change the default to at least 16K. This is only 16K pointers
> - right? Is this table the same as it was originally?

Each bucket contains an epicsMutexId (a pointer plus the OS-defined
mutex data structure itself) and an ELLLIST, which is 2 pointers and an
integer. On VxWorks a semaphore appears to need 112 bytes, so each
bucket allocates an extra 128 bytes and our default 512-entry hash table
uses up 64KB of RAM. 64-bit CPUs and workstation OSs aren't RAM-limited
like the embedded CPUs, but APS still has lots of fairly recently
installed ColdFire IOCs with only 16MB of RAM.

I just looked at the number of records in the APS accelerator IOCs; a
large number of them are around the 700-800 mark, so I think 512 buckets
is still an appropriate default. Changing that to 16K would eat up 2MB
of RAM on VxWorks, which is just not available on most of our systems.

What we could do is make the default table size larger on the 64-bit
workstation architectures. Using something like
    #define DEFAULT_SIZE (32 * sizeof(void *) * sizeof(void *))
would still give 512 buckets for 32-bit CPUs but 2048 for 64-bit CPUs.

Anybody like to comment on this idea? Base-3.16 branch?

- Andrew


> On Thu, Nov 3, 2016 at 11:27 AM, Andrew Johnson <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     Hi Murali,
> 
>     On 11/02/2016 06:21 PM, Shankar, Murali wrote:
>     >>> The 3.15 branch does contain a major performance improvement to the IOC
>     >>> when loading large numbers of database records.
>     >
>     > Awesome, I can load 100K PV's into a softIOC in a couple of seconds!
>     > Thank you so much!
> 
>     If you are loading large numbers of records also make sure that you are
>     setting the size of the IOC's hash-table before dbLoadDatabase() or
>     dbLoadRecords() in your startup script. The size argument must be a
>     power of 2 up to 64K:
>         dbPvdTableSize(65536)
>     The default size is 512, although we should probably increase that
>     nowadays. More hash buckets means more efficient name searches both at
>     load-time and by the CA name resolution task.
> 
>     - Andrew


-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Navigate by Date:
Prev: Jenkins build is still unstable: epics-base-3.14-win32s #158 APS Jenkins
Next: Re: [epics-modules/iocStats] Move MODULE_SITE_TOP definition to the end of the file (#12) Johnson, Andrew N.
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Jenkins build is back to stable : epics-base-3.14-win64s #162 APS Jenkins
Next: Re: [epics-modules/iocStats] Move MODULE_SITE_TOP definition to the end of the file (#12) Johnson, Andrew N.
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 04 Nov 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·