Difference between revisions of "Performance/Meetings/2008 05"

Revision as of 07:22, 25 August 2009

Performance/Meetings/2008/05/22

Meeting Minutes
IRC Meeting of Sun Microsystems (StarOffice) with RedFlag2000 and the Community ??
Performance Project

Date: 2008/05/22
Time: 16:04– 15:02
Meeting No.:

Agenda:

(16:04:26) mhu: Hi all, sorry for being late (traffic again)
(16:04:36) yugq: hi
(16:04:38) kuangl: hello
(16:04:44) liangjun: mhu: hello
(16:05:19) LiHeng: mhu:hello
(16:07:31) LiHeng: mhu:did you receive the mail of agenda and weekly report?
(16:09:47) mhu: sorry, yes I received your email (I was just looking it up).
(16:10:26) LiHeng: do you have some topics to discuss?
(16:11:58) mhu: Not more than you already suggested; the MID looks interesting...
(16:12:34) LiHeng: BenQ will sale thire MID in Eurpean
(16:13:00) LiHeng: first maybe Italic
(16:13:43) mhu: yes, I have heard rumours of this
(16:13:56) LiHeng: but OO in MID is slow
(16:15:14) LiHeng: Okay, we start from "Details of configtuining00 design", yugq and liangjun will talk about details of configtuning00
(16:15:18) mhu: yes, I can imagine that; do you have a (detailed) machine specification (cpufreq, memory, disk, ...)
(16:15:36) mhu: okay, yes lets start with cws...
(16:15:47) yugq: liangjun: please.
(16:16:22) LiHeng: mhu:yes, I will send specification to you
(16:16:26) LiHeng: ;)
(16:16:47) mhu: LiHeng: okay, thanks (16:19:10) yugq: OK, we want to refactor the configmgr completly. The main idea is to move some layer-merge-operation before application runtime.
(16:22:14) mhu: okay, I think we talked about this last time...
(16:22:16) yugq: re-construct the layer data struct using our simpler file format. and we will offer some tool to convert the file between which is used now and the new style file.
(16:23:41) mhu: I think you can do that, as long as you maintain the possibility to have multiple layers (e.g. a branding layer in addition to a share and a user layer).
(16:24:15) yugq: mhu: yes.
(16:24:41) yugq: and another idea is to merge the ini files.
(16:25:11) mhu: I think I understood last time, that you wanted to store the merged result in the users merged layer / home directory. ?
(16:25:57) yugq: mhu: yes.
(16:26:06) mhu: If stored in the users home directory, what size of the merged data (per user) do you expect?
(16:27:03) mhu: so, what i mean is: the size that is now used once (share) is then used for every user.
(16:27:36) yugq: mhu: actually, the size is almost the same with we using now.
(16:28:08) liangjun: mhu: I think the result of the default data merged to the share directory. and when user first use OO, we will copy the result to user home .
(16:28:13) mhu: but then times the number of users, instead of only once? or you mean the user-cache?
(16:28:39) yugq: because the share layer data is in the form of cache file in the user home directory.
(16:28:41) mhu: ...user-cache instead of shared xml?
(16:29:10) mhu: okay, understood. you are right, I forgot about the current cache. Good :-)
(16:29:21) yugq: ;-)
(16:29:43) mhu: okay, size is no problem then.
(16:30:01) liangjun: en ?
(16:30:11) liangjun: :)
(16:30:30) mhu: so, what about access control to elements that are marked "final" in the now "share" layer? How would that be maintained?
(16:30:36) LiHeng: shared xml for creating new users, and user-caching for search , modify, and ... at runtime
(16:30:42) yugq: and we will re-designed the xml file to a more effective style.
(16:31:42) mhu: as long as you maintain the logical structure (hierarchy of nodes), I think you can divide that up into different files on disk, yes.
(16:32:38) yugq: mhu: do you mean the default readonly data?
(16:32:52) mhu: yes, for example readonly data.
(16:33:21) LiHeng: mhu:more ndividual files maybe cause lots of I/O
(16:33:29) mhu: but some things might be "locked" by an administrator (security setting e.g.)
(16:33:50) liangjun: oh , I than we can set the attribute to identifier the data that is added or removed and the default data
(16:33:58) mhu: LIHeng: yes understood, number of files that need to be read is an issue
(16:34:04) LiHeng: sorry ndividual/individual
(16:34:05) liangjun: than/ thank
(16:35:04) LiHeng: yes, we want to reduce user-caching files
(16:35:39) yugq: data in share layer and user layer are seperated. and when run the application, user layer works and the modification to config data only affect the user layer.
(16:36:06) mhu: yugq: yes, that is how it is today, right?
(16:36:23) yugq: mhu: i think yes.
(16:37:03) mhu: okay, so how do you think you can maintain this property that the user cannot change some configuration data items?
(16:37:59) yugq: user can maitain the configuration data, but it is in user layer.
(16:38:14) mhu: I fact, my question is not really fair, because with todays cache, there is a theoretical method that the user can binary edit the config.
(16:38:44) yugq: Every user has it's own user data, and maintain the data of their own.
(16:38:54) mhu: yes, but...
(16:39:20) LiHeng: mhu:if some item is about security setting ,we can separate them to another files
(16:39:31) mhu: ...what I mean is a security hole: user shall not (and cannot change share layer)...
(16:39:58) mhu: ...if that is merged / cached and stored in the users home directory ...
(16:39:59) yugq: mhu: I see what you mean ...
(16:40:27) mhu: ...the user can change the data, even though an admisnstrator thinks he cannot do that.
(16:41:21) mhu: okay, but as I said, in realilty we have this problem today already with the cache.
(16:41:56) yugq: mhu: yes.
(16:42:58) mhu: and, if at all possible, we should design something that does not have this problem.
(16:43:12) LiHeng: mhu: In my opinion, if we don't want user to modify some config, we must create files which they don't have promissions
(16:43:15) yugq: mhu: and is this security hole serious?
(16:44:08) liangjun: I thank we can split some data about the security to new role ?
(16:44:11) mhu: well, I know of some customers ("paranoid" customers) which think this is a serious issue.
(16:44:12) yugq: we did not consider this before.:P
(16:44:48) mhu: yugq: no problem, the designer of the current cache also did not consider this :-)
(16:45:08) yugq: :)
(16:45:44) mhu: and, if we cannot be better than the current design, than we are at least not worse; but I would like to improve the design if possible.
(16:46:31) yugq: mhu: I think we can put the share cache in share directory.
(16:46:40) mhu: and, I would like you to understand the multitude of requirements that exited in the past, and that made the config so complicated.
(16:47:15) mhu: LiHeng: but the user cannot write to the share directory (no permission) ?
(16:48:02) LiHeng: how do you feel about we create a security caching file for every user , and deliver it to a safe place, and other settings can put into the normal caching file
(16:48:04) liangjun: I thank we can let the administrator can write to the share directory.
(16:48:42) mhu: We only need to provide a method to safely store "Locked down" / readonly config settings...
(16:48:43) liangjun: and some data about safe data we use new role .
(16:49:06) mhu: liangjun: yes, that would mean during installation, right?
(16:49:19) liangjun: no
(16:49:45) liangjun: mhu: after installed. I thank.
(16:49:51) mhu: so, when should an admistrator write to the share directory if not during install?
(16:50:25) mhu: usually, an administrator is involved only during installation ?
(16:50:56) liangjun: thank / think . sorry.
(16:50:57) LiHeng: mhu: I agree ,Maybe we append some idea for security control.
(16:52:05) mhu: LiHeng: okay, thank you. we should not forget that this security aspect exists, and that it is not correctly solved today.
(16:52:49) LiHeng: At first, we send a description of security to you, in next weekly report.
(16:53:15) mhu: okay
(16:53:35) yugq: I suggest two cache. One is in user layer, and the other is in share layer. When load the cache , we merge them. But this merging is a cache merging.
(16:53:51) LiHeng: please,check it, therefore , we must return to discuss more about it next week.
(16:54:40) mhu: yes, I think we will discuss this from time to time / review the design against this topic.
(16:54:43) LiHeng: yugq:take it easy, we need more work on it.
(16:55:02) yugq: LiHeng: yes. :)
(16:55:25) mhu: also, remember: one problem is solved, the size of the data in the users home directory :-)
(16:55:52) LiHeng: mhu:yes, we will be careful
(16:55:54) liangjun: yes :)
(16:56:17) LiHeng: mhu:now , we discuss next topic simply,OO performance job for MID or other cheap device.
(16:56:33) mhu: okay.
(16:57:06) LiHeng: do you think it necessary for do something for cheap device now?
(16:58:03) LiHeng: Mobile Internet Device will grow and user will increase more and more
(16:58:26) mhu: well, I think a build of OOo with sufficient performance on such a device would need to be built against (on) that platform.
(16:59:35) mhu: other than that, I think I need the machine spec first. performance (startup) usually is a product of cpufreq * memory * diskspeed
(16:59:48) LiHeng: parts of, MID by Lenovo , we only build it on RedFLag Desktop Version
(17:00:03) mhu: so optimization in all dimensions are probably necessary
(17:00:17) LiHeng: mhu:do we also establish simulative envaroment to test subsequent versions of OO for MID machine
(17:01:05) mhu: a simulator? I only know of valgrind. can't we test on a real device?
(17:01:50) LiHeng: no , it's not enough basic for run some tools
(17:01:54) mhu: valgrind = instruction cache simulator
(17:02:46) yugq: yes, i think valgrind like a virtual cpu.
(17:02:54) mhu: maybe plus "iogrind" if that is useful (haven't looked at it personally, only Michael Meeks has demonstrated it to me)
(17:03:26) LiHeng: oh.....
(17:04:11) yugq: I remember iogrind is developed by Michael Meeks.
(17:04:32) mhu: but to really see why OOo is slow on the device, we would need to measure some data on the device itself, if only to establish a realistic simulation.
(17:04:32) LiHeng: sometimes, MID have special hardware and different liberary
(17:05:13) mhu: LiHeng: that is what I meant with "detailed specification" :-)
(17:06:04) LiHeng: yes, i will gather them into a report and to send to you.
(17:06:43) LiHeng: it's a new job, for us, we also need more and more topic for it
(17:06:50) mhu: okay, thanks. It will not be an easy task to do, but if done right on MID, it will improve for all devices incl. desktops.
(17:08:00) mhu: I think it is also an interesting job; the idea being that every device should have an OOo installed :-)
(17:08:50) mhu: even factory preinstalled :-) :-)
(17:09:01) yugq: :-D
(17:10:10) LiHeng: that all today
(17:10:23) mhu: okay, I don' thave more also.
(17:11:01) LiHeng: mhu:please help us to check plan of security
(17:11:20) mhu: LiHeng: yes, of course I will help you.
(17:11:40) LiHeng: okay, bye.
(17:11:55) mhu: bye all, see you next Thursday.
(17:12:05) yugq: bye.
(17:12:15) liangjun: bye.

Go back