Hi Yong,
On 06/06/2014 06:24 AM, Hu, Yong wrote:
> 3. I think it is very difficult to configure architecture-specific
> default settings. I saw some IOCs running linux-x86, but they have
> very limited memory.
Actually it should be quite easy to do this inside EPICS Base; I was
suggesting that the compiled-in default value should be large on
operating systems that have virtual memory and small on embedded OSs,
and I can think of several ways to do this so I may implement it myself.
Note that all linux-x86 systems use virtual memory, and as such the OS
only actually allocates physical RAM for a buffer once it starts having
data put into it. If you set EPICS_CA_MAX_ARRAY_BYTES to a large number
the CA libraries will request the appropriate amount of memory but
initially the OS will reserve virtual memory space for the allocation,
but it will then map physical memory for the parts of the buffer that
are actually used. The OS will not reserve physical memory for the
unused parts, and the client program will never notice.
The only time when what I have described above is not true is if you
configure your Linux kernel to never overcommit memory allocations (i.e.
/proc/sys/vm/overcommit_memory = 2) and you don't have a swap file.
> 4. We are in a big data era. But we still keep the default
> EPICS_CA_MAX_ARRAY_BYTES to a low value at 16K bytes mainly because
> there are some tiny IOCs which have limited memory resource. I
> believe that most modern CA clients such as EDM, CSS, etc. should
> have have no problem with EPICS_CA_MAX_ARRAY_BYTES to tens of or even
> hundreds of Megabytes. How about the idea of creating another
> environment variable "EPICS_CAS_MAX_ARRAY_BYTES" with a default low
> value at 16K dedicated for CA server (IOC) and using
> EPICS_CA_MAX_ARRAY_BYTES with a default high value for CA client? The
> configurations of max_array_bytes on the client side and on the
> server side are independent, but currently we are using a single
> environment variable for two independent settings. Having said that,
> introducing a new environment variable may introduce other problems.
I think being able to configure the server separately from the client is
probably a good one, since we currently cannot set an IOC to serve big
arrays without also reserving large buffers for its CA client library
side as well. This shouldn't be hard to add to Base. However I still
think that the compiled-in default settings for the two parameters
should be different on the two classes of OS (VM vs. Embedded).
> 5. Any progress on adding new parameters dynamically:
> https://blueprints.launchpad.net/epics-base/+spec/epicsconf? Will it
> solve the problems related to EPICS_CA_MAX_ARRAY_BYTES?
Not that I know of.
> 6. How about the idea of auto-configuring of EPICS_CA_MAX_ARRAY_BYTES
> on the server side?
I would be very nervous about doing that, even if it was possible (which
I think is unlikely). On embedded IOCs with limited amounts of RAM that
could cause problems which might be very hard to track down.
- Andrew
--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock
- References:
- auto-configure EPICS_CA_MAX_ARRAY_BYTES in catools/caget Hu, Yong
- Re: auto-configure EPICS_CA_MAX_ARRAY_BYTES in catools/caget Eric Norum
- Re: auto-configure EPICS_CA_MAX_ARRAY_BYTES in catools/caget Andrew Johnson
- RE: auto-configure EPICS_CA_MAX_ARRAY_BYTES in catools/caget Hu, Yong
- Navigate by Date:
- Prev:
Re: auto-configure EPICS_CA_MAX_ARRAY_BYTES in catools/caget Konrad, Martin
- Next:
RE: auto-configure EPICS_CA_MAX_ARRAY_BYTES in catools/caget Hu, Yong
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: auto-configure EPICS_CA_MAX_ARRAY_BYTES in catools/caget Hu, Yong
- Next:
Re: auto-configure EPICS_CA_MAX_ARRAY_BYTES in catools/caget Konrad, Martin
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|