How should I test squid-smp ??
Hello, I have multi-core(32) core server here, Now the squid-smp is running with two threads(schedule and dispatch), Some bugs may be there. I want to test squid here in my lab, please tell me a mechanism or strategy that must be used for rigorous testing Any tool that is available, because i know i have not locked everything from simultaneous accesses... -- Mr. S. H. Malave Computer Science Engineering Department, Walchand College of Engineering,Sangli. sachinmal...@wce.org.in
Re: Features/SmpScale
On Mon, Dec 21, 2009 at 6:21 PM, Amos Jeffries squ...@treenet.co.nz wrote: Sachin Malave wrote: Dear Amos, Thank you for updating wiki.squid-cache.org/Features/SmpScale, now ideas are more clear, I have already started working on the architecture that is proposed... Thank you for your thanks. Which part and which layer are you working towards now? (the earlier work you have already done was towards mid-layer) If it was top-layer there are a few speed bumps we've already identified and not yet documented: YES, IT IS. Missing Pieces (most to least difficult): * Mechanism to replace SquidConf:cache_dir (proposal cache_disk /media/path SIZE ) - a set of disk entries. Master instance to load and portion off each child instance with one or more disks. The child instance to determine what types of storage (old SquidConf:cache_dir types) to be stored there and what sizes will fit in the disk max given.come * Mechanism to handle many SquidConf:http_port and other listening port directives - Master instance doing accept and passing to children? or all children listening on all ports on a first-accept-wins basis? * Mechanism needed to replace existing method of master instance monitoring for a dead child instance. Perhapse listening socket based? * Mechanism to split cache_mem between all child instances. Or do we leave this as-is and call it a per-instance allocation? * Mechanism to keep unique_hostname unique per instance? do we even need to? is it safer to consider the whole bunch of instances one unique host and leave the existing code preventing complicated loops paths between instances?) Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.15 I THINK YOU HAVE GIVEN ME ENOUGH MATERIAL FOR THIS ACADEMIC SEMESTER :) Before everything i will concentrate on all above mentioned points... I need some time for analysis. will be back soon with solutions ... -- Mr. S. H. Malave Computer Science Engineering Department, Walchand College of Engineering,Sangli. sachinmal...@wce.org.in
Re: squid-smp: synchronization issue solutions
On Tue, Nov 24, 2009 at 6:08 PM, Henrik Nordstrom hen...@henriknordstrom.net wrote: ons 2009-11-25 klockan 00:55 +1300 skrev Amos Jeffries: I kind of mean that by the smaller units. I'm thinking primarily here of the internal DNS. It's API is very isolated from the work. And also a good example of where the CPU usage is negligible. And no, it's not really that isolated. It's allocating data for the response which is then handed to the caller, and modified in other parts of the code via ipcache.. But yes, it's a good example of where one can try scheduling the processing on a separate thread to experiment with such model. Its not only about how much CPU usage we are distributing among threads, But we also have to consider that thread works only inside its own memory if shared data is less( must be), If we could let thread to work inside its own private memory maximum time, it is worth to create thread so a thread scheduled on a core accessing its own cache will definitely speed up our squid. Yes we have to consider how OS is doing read/write operations, Because all write operations must be done serially if using WRITE THROUGH policy to update all levels of memory ( cache or main), otherwise no issues Regards Henrik -- Mr. S. H. Malave Computer Science Engineering Department, Walchand College of Engineering,Sangli. sachinmal...@wce.org.in
Re: squid-smp: synchronization issue solutions
On Wed, Nov 25, 2009 at 7:48 AM, Amos Jeffries squ...@treenet.co.nz wrote: On Tue, 24 Nov 2009 16:13:37 -0700, Alex Rousskov rouss...@measurement-factory.com wrote: On 11/20/2009 10:59 PM, Robert Collins wrote: On Tue, 2009-11-17 at 08:45 -0700, Alex Rousskov wrote: Q1. What are the major areas or units of asynchronous code execution? Some of us may prefer large areas such as http_port acceptor or cache or server side. Others may root for AsyncJob as the largest asynchronous unit of execution. These two approaches and their implications differ a lot. There may be other designs worth considering. I'd like to let people start writing (and perf testing!) patches. To unblock people. I think the primary questions are: - do we permit multiple approaches inside the same code base. E.g. OpenMP in some bits, pthreads / windows threads elsewhere, and 'job queues' or some such abstraction elsewhere ? (I vote yes, but with caution: someone trying something we don't already do should keep it on a branch and really measure it well until its got plenty of buy in). I vote for multiple approaches at lower levels of the architecture and against multiple approaches at highest level of the architecture. My Q1 was only about the highest levels, BTW. For example, I do not think it is a good idea to allow a combination of OpenMP, ACE, and something else as a top-level design. Understanding, supporting, and tuning such a mix would be a nightmare, IMO. On the other hand, using threads within some disk storage schemes while using processes for things like cache may make a lot of sense, and we already have examples of some of that working. OpenMP seems almost unanimous negative by the people who know it. OK This is why I believe that the decision of processes versus threads *at the highest level* of the architecture is so important. Yes, we are, can, and will use threads at lower levels. There is no argument there. The question is whether we can also use threads to split Squid into several instances of major areas like client side(s), cache(s), and server side(s). See Henrik's email on why it is difficult to use threads at highest levels. I am not convinced yet, but I do see Henrik's point, and I consider the dangers he cites critical for the right Q1 answer. - If we do *not* permit multiple approaches, then what approach do we want for parallelisation. E.g. a number of long lived threads that take on work, or many transient threads as particular bits of the code need threads. I favour the former (long lived 'worker' threads). For highest-level models, I do not think that one job per thread/process, one call per thread/process, or any other one little short-lived something per thread/process is a good idea. I do believe we have to parallelize major areas, and I think we should support multiple instances of some of those areas (e.g., multiple client sides). Each major area would be long-lived process/thread, of course. Agreed. mostly. As Rob points out the idea is for one small'ish pathway of the code to be run N times with different state data each time by a single thread. Sachins' initial AcceptFD thread proposal would perhapse be exemplar for this type of thread. Where one thread does the comm layer; accept() through to the scheduling call hand-off to handlers outside comm. Then goes back for the next accept(). The only performance issue brought up was by you that its particular case might flood the slower main process if done first. Not all code can be done this way. Overheads are simply moving the state data in/out of the thread. IMO starting/stopping threads too often is a fairly bad idea. Most events will end up being grouped together into types (perhapse categorized by component, perhapse by client request, perhapse by pathway) with a small thread dedicated to handling that type of call. Again for higher-level models, I am also skeptical that it is a good idea to just split Squid into N mostly non-cooperating nearly identical instances. It may be the right first step, but I would like to offer more than that in terms of overall performance and tunability. The answer to that is: of all the SMP models we theorize, that one is the only proven model so far. Administrators are already doing it with all the instance management manually handled on quad+ core machines. With a lot of performance success. In last nights discussion on IRC we covered what issues are outstanding from making this automatic and all are resolvable except cache index. It's not easily shareable between instances. I hope the above explains why I consider Q1 critical for the meant highest level scope and why we already use processes and threads is certainly true but irrelevant within that scope. Thank you, Alex. Thank you for clarifying that. I now think we are all more or less headed in the same direction(s). With three models proposed for the
Re: squid-smp: synchronization issue solutions
On Mon, Nov 16, 2009 at 9:43 PM, Alex Rousskov rouss...@measurement-factory.com wrote: On 11/15/2009 11:59 AM, Sachin Malave wrote: Since last few days i am analyzing squid code for smp support, I found one big issue regarding debugs() function, It is very hard get rid of this issue as it is appearing at almost everywhere in the code. So for testing purpose i have disable the debug option in squid.conf as follows --- debug_options 0,0 --- Well this was only way, as did not want to spend time on this issue. You can certainly disable any feature as an intermediate step as long as the overall approach allows for the later efficient support of the temporary disabled feature. Debugging is probably the worst feature to disable though because without it we do not know much about Squid operation. I agree, We should find a way to re-enable this feature. It is temporarily disabled... Off-course locking debugs() was not the solution thats why it is disabled... Now concentrating on locking mechanism... I would not recommend starting with such low-level decisions as locking mechanisms. We need to decide what needs to be locked first. AFAIK, there is currently no consensus whether we start with processes or threads, for example. The locking mechanism would depend on that. As OpenMP library is widely supported by almost all platforms and compilers, I am inheriting locking mechanism from the same Just include omp.h compile code with -fopenmp option if using gcc, Other may use similar thing on their platform, Well that is not a big issue.. After spending 2 minutes on openmp.org, I am not very excited about using OpenMP. Please correct me if I am wrong, but OpenMP seems to be: - An approach or model requiring compiler support and language extensions. It is _not_ a library. You examples with #pragmas is a good illustration. We have to use something to create and manage threads, there are some other libraries and models also but i feel we need something that will work on all platforms, Important features of OPENMP, you might be interested in... ** If your compiler is not supporting OPENMP then you dont have to do any special thing, Compiler simply ignores these #pragmas.. and runs codes as if they are in sequential single thread program, without affecting the end goal. ** Programmers need not to create any locking mechanism and worry about critical sections, ** By default it creates number threads equals to processors( * cores per processor) in your system. ** Its fork and join model is scalable.. ( Off-course we must find such areas in exiting code) ** OPENMP is OLD but still growing .. Providing new features with new releases.. Think about other threading libraries, I think their developments are stopped, Some of them are not freely available, some of them are available only on WINDOWS.. ** IT IS FREE and OPEN-SOURCE like us.. ** INTEL just has released TBB ( Threading Building Blocks), But i doubt its performance on AMD ( non-intel ) hardware. ** You might be thinking about old Pthreads, But i think OPENMP is very safe and better than pthreads for programmers SPECIALLY ONE WHO IS MAKING CHANGES IN EXISTING CODES. and easy to debugs. please think about my last point... :) - Designed for parallelizing computation-intensive programs such as various math models running on massively parallel computers. AFAICT, the OpenMP steering group is comprised of folks that deal with such models in such environments. Our environment and performance goals are rather different. But that doesnt mean that we can not have independent threads, Only thing is that we have to start these threads in main(), because main never ends.. Otherwise those independent threads will die after returning to calling function.. 1. hash_link LOCKED 2. dlink_list LOCKED 3. ipcache, fqdncache LOCKED, 4. FD / fde handling ---WELL, SEEMS NOT CREATING PROBLEM, If any then please discuss. 5. statistic counters --- NOT LOCKED ( I know this is very important, But these are scattered all around squid code, Write now they may be holding wrong values) 6. memory manager --- DID NOT FOLLOW 7. configuration objects --- DID NOT FOLLOW I worry that the end result of this exercise would produce a slow and buggy Squid for several reasons: - Globally locking low-level but interdependent objects is likely to create deadlocks when two or more locked objects need to lock other locked objects in a circular fashion. is there any other option ? As discussed, Amos is trying to make these areas as independent as possible. So that we would have less locking in the code. - Locking low-level objects without an overall performance-aware plan is likely to result in performance-killing competition for critical locks. I believe that with the right design, many locks can be avoided. I think our first questions
Re: squid-smp: synchronization issue solutions
On Tue, Nov 17, 2009 at 9:15 PM, Alex Rousskov rouss...@measurement-factory.com wrote: On 11/17/2009 04:09 AM, Sachin Malave wrote: After spending 2 minutes on openmp.org, I am not very excited about using OpenMP. Please correct me if I am wrong, but OpenMP seems to be: - An approach or model requiring compiler support and language extensions. It is _not_ a library. You examples with #pragmas is a good illustration. Important features of OPENMP, you might be interested in... ** If your compiler is not supporting OPENMP then you dont have to do any special thing, Compiler simply ignores these #pragmas.. and runs codes as if they are in sequential single thread program, without affecting the end goal. ** Programmers need not to create any locking mechanism and worry about critical sections, ** By default it creates number threads equals to processors( * cores per processor) in your system. All of the above make me think that OPENMP-enabled Squid may be significantly slower than multi-instance Squid. I doubt OPENMP is so smart that it can correctly and efficiently orchestrate the work of Squid threads that are often not even visible/identifiable in the current code. - Designed for parallelizing computation-intensive programs such as various math models running on massively parallel computers. AFAICT, the OpenMP steering group is comprised of folks that deal with such models in such environments. Our environment and performance goals are rather different. But that doesnt mean that we can not have independent threads, It means that there is a high probability that it will not work well for other, very different, problem areas. It may work, but not work well enough. I think our first questions should instead include: Q1. What are the major areas or units of asynchronous code execution? Some of us may prefer large areas such as http_port acceptor or cache or server side. Others may root for AsyncJob as the largest asynchronous unit of execution. These two approaches and their implications differ a lot. There may be other designs worth considering. See my sample codes, I sent in last mail.. There i have separated out the schedule() and dial() functions, Where one thread is registering calls in AsyncCallQueue and another is dispatching them.. Well, We can concentrate on other areas also scheedule() and dial() are low level routines that are irrelevant for Q1. Q2. Threads versus processes. Depending on Q1, we may have a choice. The choice will affect the required locking mechanism and other key decisions. If you are planning to use processes then it is as good as running multiple squids on single machine.., I am not planning to use processes yet, but if they are indeed as good as running multiple Squids, that is a plus. Hopefully, we can do better than multi-instance Squid, but we should be at least as bad/good. Only thing is they must be accepting requests on different ports... But if we want distribute single squid's work then i feel threading is the best choice.. You can have a process accepting a request and then forwarding the work to another process or receiving a cache hit from another process. Inter-process communication is slower than inter-thread communication, but it is not impossible. I AM THINKING ABOUT HYBRID OF BOTH... Somebody might implement process model, Then we would merge both process and thread models .. together we could have a better squid.. :) What do u think? I doubt we have the resources to do a generic process model so I would rather decide on a single primary direction (processes or threads) and try to generalize that later if needed. However, a process (if we decide to go down that route) may still have lower-level threads, but that is a secondary question/decision. OK then, please come precisely, What exactly you are thinking ? tell me areas where i should concentrate ? I want to know what exactly is going in your mind so that i could start working and experimenting in that direction ... :) meanwhile i would also try to experiment with threading, i am doing right now, it would help me when we start actual development, is that OK ? Thanx.. Cheers, Alex. -- Mr. S. H. Malave Computer Science Engineering Department, Walchand College of Engineering,Sangli. sachinmal...@wce.org.in
squid-smp: synchronization issue solutions
Hello,
Since last few days i am analyzing squid code for smp support, I found
one big issue regarding debugs() function, It is very hard get rid of
this issue as it is appearing at almost everywhere in the code. So for
testing purpose i have disable the debug option in squid.conf as
follows
---
debug_options 0,0
---
Well this was only way, as did not want to spend time on this issue.
Now concentrating on locking mechanism...
As OpenMP library is widely supported by almost all platforms and
compilers, I am inheriting locking mechanism from the same
Just include omp.h compile code with -fopenmp option if using gcc,
Other may use similar thing on their platform, Well that is not a big
issue..
BUT, is it wise to take support from this library? Please discuss on
this issue I felt it is really easy to manage threads and
critical sections if we use OPENMP.
AS DISCUSSED BEFORE.. AND details available on
http://wiki.squid-cache.org/Features/SmpScale
I think, I have solved SOME critical section problems in existing squid code.
*AsyncCallQueue.cc***
void AsyncCallQueue::schedule(AsyncCall::Pointer call)
{
#pragma omp critical (AsyncCallQueueLock_c) // HERE IS THE LOCK
{
if (theHead != NULL) { // append
assert(!theTail-theNext);
theTail-theNext = call;
theTail = call;
} else { // create queue from cratch
theHead = theTail = call;
}
}
//AND THEN
AsyncCallQueue::fireNext()
{
AsyncCall::Pointer call;
#pragma omp critical (AsyncCallQueueLock_c) // SAME LOCK
{
call = theHead;
theHead = call-theNext;
call-theNext = NULL;
if (theTail == call)
theTail = NULL;
}
}
ITS WORKING, AS SAME CRITICAL SECTIONS (i.e AsyncCallQueueLock_c) CAN
NOT BE CALLED SIMULTANEOUSLY
**
Well in the same way following thing as appearing on
/Features/SmpScale are also locked( May be incompletely)
1. hash_link LOCKED
2. dlink_list LOCKED
3. ipcache, fqdncache LOCKED,
4. FD / fde handling ---WELL, SEEMS NOT CREATING PROBLEM, If any then
please discuss.
5. statistic counters --- NOT LOCKED ( I know this is very important,
But these are scattered all around squid code, Write now they may be
holding wrong values)
6. memory manager --- DID NOT FOLLOW
7. configuration objects --- DID NOT FOLLOW
AND FINALLY, Two sections in EventLoop.cc are separated and executed
in two threads simultaneously
as follows (#pragma lines added in existing code, no other changes)
**EventLoop.cc
#pragma omp parallel sections //PARALLEL SECTIONS
{
#pragma omp section //THREAD-1
{
if (waitingEngine != NULL)
checkEngine(waitingEngine, true);
if (timeService != NULL)
timeService-tick();
checked = true;
}
#pragma omp section //THREAD-2
{
while(1)
{
if ( lastRound == true) break;
sawActivity = dispatchCalls();
if (sawActivity)
runOnceResult = false;
if(checked == true) lastRound = true;
}
}
}
May need deep testing , but it is working..
am I on the right path ?
Thank you,
--
Mr. S. H. Malave
Computer Science Engineering Department,
Walchand College of Engineering,Sangli.
sachinmal...@wce.org.in
Happy Diwali to all : squid-smp
Hello, Here in India we are celebrating DIWALI festival. So I am on vacation for next 5 days. Will continue squid-smp discussion soon Happy Diwali to all.. -- Mr. S. H. Malave Computer Science Engineering Department, Walchand College of Engineering,Sangli. sachinmal...@wce.org.in
squid-smp
-- Forwarded message -- From: Sachin Malave sachinmal...@gmail.com Date: Tue, Oct 13, 2009 at 7:56 AM Subject: Re: squid-smp To: Amos Jeffries squ...@treenet.co.nz Cc: Henrik Nordstrom hen...@henriknordstrom.net, Squid Developers squid-dev@squid-cache.org On Mon, Oct 12, 2009 at 8:33 PM, Amos Jeffries squ...@treenet.co.nz wrote: On Tue, 13 Oct 2009 00:29:56 +0200, Henrik Nordstrom hen...@henriknordstrom.net wrote: fre 2009-10-09 klockan 01:50 -0400 skrev Sachin Malave: I think it is possible to have a thread , which will be watching AsyncCallQueue, if it finds an entry there then it will execute the dial() function. Except that none of the dialed AsyncCall handlers is currently thread safe.. all expect to be running in the main thread all alone. Which raises the issue of whether to add a second main queue loop for thread-safe calls. Then schedule calls which have been audited and found safe to that queue instead of the current main queue. Usage would be low to start with but would allow ongoing incremental SMP improvements by gradually migrating chunks of code to be thread-safe. An alternate would be thread-safe the queue and add a flag to say particular calls are thread-safe. That would mean walking the queue repeatedly looking for them. Which is perhaps less desirable at the start of conversion when few calls are threaded. But gains in utility relative to the thread-safety progress. This involves a small amount of extra code in schedule() to flag which queue the calls is sent to, and a chunk of extra memory for duplicate queue management objects. --- Ok if that is possible then would like to make those changes, Either of them will be tried... One more thing... Are you thinking about spawning multiple threads or single thread separated from main is sufficient for handling all scheduled calls. Here multiple threads means, we could have threads all trying to dial entries in AsyncCallQueue simultaneously. --- can we separate dispatchCalls() in EventLoop.cc for that purpose? We can have a thread executing distatchCalls() continuously This is an end-goal. Jumping straight there for everything is usually a mistake. But good to re-state it anyway. and if error condition occurs it is written in error shared variable. which is then read by main thread executing mainLoop... in the same way returned dispatchedSome can also be passed to main thread... I think I follow. You mean something like the way errno works in the OS? Doing that would be a major crutch in Squid. I'd rather have an error object per-job (field in the job descriptor object) which the job handlers can use according to the job needs. Some will result in data sent back to the client, some in a completely altered handling pathway. Amos -- Mr. S. H. Malave Computer Science Engineering Department, Walchand College of Engineering,Sangli. sachinmal...@wce.org.in
Re: squid-smp
On Tue, Oct 13, 2009 at 8:12 AM, Amos Jeffries squ...@treenet.co.nz wrote: Sachin Malave wrote: On Mon, Oct 12, 2009 at 8:33 PM, Amos Jeffries squ...@treenet.co.nz mailto:squ...@treenet.co.nz wrote: On Tue, 13 Oct 2009 00:29:56 +0200, Henrik Nordstrom hen...@henriknordstrom.net mailto:hen...@henriknordstrom.net wrote: fre 2009-10-09 klockan 01:50 -0400 skrev Sachin Malave: I think it is possible to have a thread , which will be watching AsyncCallQueue, if it finds an entry there then it will execute the dial() function. Except that none of the dialed AsyncCall handlers is currently thread safe.. all expect to be running in the main thread all alone. Which raises the issue of whether to add a second main queue loop for thread-safe calls. Then schedule calls which have been audited and found safe to that queue instead of the current main queue. Usage would be low to start with but would allow ongoing incremental SMP improvements by gradually migrating chunks of code to be thread-safe. An alternate would be thread-safe the queue and add a flag to say particular calls are thread-safe. That would mean walking the queue repeatedly looking for them. Which is perhaps less desirable at the start of conversion when few calls are threaded. But gains in utility relative to the thread-safety progress. This involves a small amount of extra code in schedule() to flag which queue the calls is sent to, and a chunk of extra memory for duplicate queue management objects. --- Ok if that is possible then would like to make those changes, Either of them will be tried... One more thing... Are you thinking about spawning multiple threads or single thread separated from main is sufficient for handling all scheduled calls. Here multiple threads means, we could have threads all trying to dial entries in AsyncCallQueue simultaneously. That would be up to you. I had not thought more than one dialer thread per CPU necessary at this stage. Though with both verified thread-safe calls and a thread-safe queue, multiple dialer threads should not be an issue. Doing more than necessary would merely be a waste of resources. Yeah ! I am also thinking the same... Squid would essentially segment into multiple 'main' threads / dialers running one to a CPU and sharing minimal amounts of state. Slightly more efficient and far easier to configure than current setups of multiple interlinked Squid instances. Ok, This could be done... will give good performance results.. But want to know more about this, please come again with more precise definition. Are you talking about multi-instance squid ? http://wiki.squid-cache.org/MultipleInstances. Without knowing too much, I'm assuming the Job ID can be used to identify calls a particular thread/job runs. Amos --- can we separate dispatchCalls() in EventLoop.cc for that purpose? We can have a thread executing distatchCalls() continuously This is an end-goal. Jumping straight there for everything is usually a mistake. But good to re-state it anyway. and if error condition occurs it is written in error shared variable. which is then read by main thread executing mainLoop... in the same way returned dispatchedSome can also be passed to main thread... I think I follow. You mean something like the way errno works in the OS? Doing that would be a major crutch in Squid. I'd rather have an error object per-job (field in the job descriptor object) which the job handlers can use according to the job needs. Some will result in data sent back to the client, some in a completely altered handling pathway. Amos -- Mr. S. H. Malave Computer Science Engineering Department, Walchand College of Engineering,Sangli. sachinmal...@wce.org.in mailto:sachinmal...@wce.org.in -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19 Current Beta Squid 3.1.0.14 -- Mr. S. H. Malave Computer Science Engineering Department, Walchand College of Engineering,Sangli. sachinmal...@wce.org.in
Re: Squid-smp : Please discuss
On Mon, Sep 14, 2009 at 6:43 AM, Amos Jeffries squ...@treenet.co.nz wrote:
I think we should take this on-list so the others with more detailed
knowledge can give advice in case I have my facts wrong about AsyncCalls...
I mean some mutex/lock on AsyncCallQueue so the multiple threads can do
AsyncCallQueue::schedule(call) without pointer collisions with theTail and
theHead, when they setup the first read of an accepted()'d FD.
For example something like this...
thread #1:
while ( events to dial ) {
queuedEventX.dial()
}
I think it is possible to have a thread , which will be watching
AsyncCallQueue, if it finds an entry there then it will execute the
dial() function.
can we separate dispatchCalls() in EventLoop.cc for that purpose? We
can have a thread executing distatchCalls() continuously and if error
condition occurs it is written in error shared variable. which
is then read by main thread executing mainLoop... in the same way
returned dispatchedSome can also be passed to main thread...
we need to lock the AsyncCallQueue using some locking mechanism. If
that is done, is there any other variable that also must be considered
?
And no need to create a separate thread for schedule(), as it is not
doing much computations there, main thread can handle it easily...
thread #2:
while( listening for new connections ) {
newFD = accept()
readFromNewFd = new AsyncCallPointer...
AsyncCallQueue::schedule(readFromNewFd);
}
Need some time for further analysis...
Thank you so much..
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE19
Current Beta Squid 3.1.0.13
--
Mr. S. H. Malave
Computer Science Engineering Department,
Walchand College of Engineering,Sangli.
sachinmal...@wce.org.in
squid-smp
As discussed before...
On Mon, Sep 14, 2009 at 6:43 AM, Amos Jeffries squ...@treenet.co.nz wrote:
I think we should take this on-list so the others with more detailed
knowledge can give advice in case I have my facts wrong about AsyncCalls...
I mean some mutex/lock on AsyncCallQueue so the multiple threads can do
AsyncCallQueue::schedule(call) without pointer collisions with theTail and
theHead, when they setup the first read of an accepted()'d FD.
For example something like this...
thread #1:
while ( events to dial ) {
queuedEventX.dial()
}
I think it is possible to have a thread , which will be watching
AsyncCallQueue, if it finds an entry there then it will execute the
dial() function.
can we separate dispatchCalls() in EventLoop.cc for that purpose? We
can have a thread executing distatchCalls() continuously and if error
condition occurs it is written in error shared variable. which
is then read by main thread executing mainLoop... in the same way
returned dispatchedSome can also be passed to main thread...
we need to lock the AsyncCallQueue using some locking mechanism. If
that is done, is there any other variable that also must be considered
?
And no need to create a separate thread for schedule(), as it is not
doing much computations there, main thread can handle it easily...
thread #2:
while( listening for new connections ) {
newFD = accept()
readFromNewFd = new AsyncCallPointer...
AsyncCallQueue::schedule(readFromNewFd);
}
Need some time for further analysis...
Thank you so much..
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE19
Current Beta Squid 3.1.0.13
--
Mr. S. H. Malave
Computer Science Engineering Department,
Walchand College of Engineering,Sangli.
sachinmal...@wce.org.in
Re: R: Squid-smp : Please discuss
On Tue, Sep 15, 2009 at 2:39 AM, Guido Serassio guido.seras...@acmeconsulting.it wrote: Hi, And current generation libraries are also far better than older, like OpenMP, creating threads and handling synchronization issues in OpenMP is very easy... Automatic locks are provided, u need not to design your own locking mechanisms Just a statement and u can lock the shared variable... Then the major work remains is to identify the shared access. I WANT TO USE OPENMP library. ANY suggestions. Just a multi platform consideration: Don't forget that such libraries like OpenMP could not be available on all Squid supported platforms. As example, on Windows OpenMP is available only using gcc 4.3.2 and later or MS Visual Studio 2008. But MSYS + MinGW provides gcc 3.4.5 and the Squid 3 Visual Studio Project is based on Visual Studio 2005. So, please, we should be very careful when thinking about Squid MP. Well, if that is so. We will use OpenMP 2.0 standard which is available on Visual Studio 2005 also Tasking model is added in 3.0 version, which has changed whole OpenMP programming style but it is not needed in our case, I guess.. Thanks for pointing out this.. Will try to use 2.0 version. Please tell me if you have different library in your mind. Regards Guido Serassio Acme Consulting S.r.l. Microsoft Gold Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: guido.seras...@acmeconsulting.it WWW: http://www.acmeconsulting.it
Re: R: Squid-smp : Please discuss
On Tue, Sep 15, 2009 at 9:47 AM, Matt W. Benjamin m...@linuxbox.com wrote: Hi all, I'm quite sure that you're going to do what you always do, but my belief is, it's fruitless to look to external libraries and (especially) more complex language infrastructure as a substitute for the old-fashioned work of working through the code, subsystem by subsystem, to establish MP safety. The result of this sort of approach, as I think the result has been from the transition to C++ as a whole, to could very likely be to: a. increase the size of b. potentially, -reduce- the profiled performance of c. and I think very likely, reduce the overall value of the codebase as a whole. Yes, that is also one of the issues.. squid3 codes(c++) are very complicated compared to original squid written in c, That already have increased size of source codes.. But if we use external library like openmp then i dont think we need to make much changes in actual codes. But that is only possible if we find blocks in existing codes which could be executed by different threads... I am trying hard to analyze it for the same would like to spend some time on it before come to conclusion. Will sure not disturb everything. And also want to keep codes as simple as possible Will come up with new ideas soon Thanks Matt - Sachin Malave sachinmal...@gmail.com wrote: On Tue, Sep 15, 2009 at 2:39 AM, Guido Serassio guido.seras...@acmeconsulting.it wrote: Hi, And current generation libraries are also far better than older, like OpenMP, creating threads and handling synchronization issues in OpenMP is very easy... Automatic locks are provided, u need not to design your own locking mechanisms Just a statement and u can lock the shared variable... Then the major work remains is to identify the shared access. I WANT TO USE OPENMP library. ANY suggestions. Just a multi platform consideration: Don't forget that such libraries like OpenMP could not be available on all Squid supported platforms. As example, on Windows OpenMP is available only using gcc 4.3.2 and later or MS Visual Studio 2008. But MSYS + MinGW provides gcc 3.4.5 and the Squid 3 Visual Studio Project is based on Visual Studio 2005. So, please, we should be very careful when thinking about Squid MP. Well, if that is so. We will use OpenMP 2.0 standard which is available on Visual Studio 2005 also Tasking model is added in 3.0 version, which has changed whole OpenMP programming style but it is not needed in our case, I guess.. Thanks for pointing out this.. Will try to use 2.0 version. Please tell me if you have different library in your mind. Regards Guido Serassio Acme Consulting S.r.l. Microsoft Gold Certified Partner Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY Tel. : +39.011.9530135 Fax. : +39.011.9781115 Email: guido.seras...@acmeconsulting.it WWW: http://www.acmeconsulting.it -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 -- Mr. S. H. Malave MTech, Computer Science Engineering Dept., Walchand College of Engineering, Sangli. Mob. 9860470739 sachinmal...@wce.org.in
Re: Squid-smp : Please discuss
On Tue, Sep 15, 2009 at 1:18 AM, Adrian Chadd adr...@squid-cache.org wrote: Guys, Please look at what other multi-CPU network applications do, how they work and don't work well, before continuing this kind of discussion. Everything that has been discussed has already been done to death elsewhere. Please don't re-invent the wheel, badly. Adrian 2009/9/15 Robert Collins robe...@robertcollins.net: On Tue, 2009-09-15 at 14:27 +1200, Amos Jeffries wrote: RefCounting done properly forms a lock on certain read-only types like Config. Though we are currently handling that for Config by leaking the memory out every gap. SquidString is not thread-safe. But StringNG with its separate refcounted buffers is almost there. Each thread having a copy of StringNG sharing a SBuf equates to a lock with copy-on-write possibly causing issues we need to look at if/when we get to that scope. General rule: you do /not/ want thread safe objectse for high usage objects like RefCount and StringNG. synchronisation is expensive; design to avoid synchronisation and hand offs as much as possible. -Rob Yes synchronization is always expensive . So we must target only those areas where shared data is updated infrequently. Also if we are making thread then the amount of work done must be more as compared to overheads required in thread creation, synchronization scheduling. If we try to provide locks to existing data structures then synchronization factor will definitely affect to our design. Redesigning of such structures and there behavior is time consuming and may change whole design of the Squid. Whatever it may be.. WE HAVE TO MOVE SQUID TO MULTI-CORE... because future is MULTI-CORE.. Anyways still there are many question in my mind but as am new here, would like to spend some time in analysis of current design PLEASE cope with my speed -- Mr. S. H. Malave MTech, Computer Science Engineering Dept., Walchand College of Engineering, Sangli. Mob. 9860470739 sachinmal...@wce.org.in
Re: Squid-smp : Please discuss
On Tue, Sep 15, 2009 at 1:38 AM, Adrian Chadd adr...@squid-cache.org wrote: 2009/9/15 Sachin Malave sachinmal...@gmail.com: On Tue, Sep 15, 2009 at 1:18 AM, Adrian Chadd adr...@squid-cache.org wrote: Guys, Please look at what other multi-CPU network applications do, how they work and don't work well, before continuing this kind of discussion. Everything that has been discussed has already been done to death elsewhere. Please don't re-invent the wheel, badly. Yes synchronization is always expensive . So we must target only those areas where shared data is updated infrequently. Also if we are making thread then the amount of work done must be more as compared to overheads required in thread creation, synchronization scheduling. Current generation CPUs are a lot, lot better at the thread-style sync primitives than older CPUs. There's other things to think about, such as lockless queues, transactional memory hackery, atomic instructions in general, etc, etc, which depend entirely upon the type of hardware being targetted. If we try to provide locks to existing data structures then synchronization factor will definitely affect to our design. Redesigning of such structures and there behavior is time consuming and may change whole design of the Squid. Adrian And current generation libraries are also far better than older, like OpenMP, creating threads and handling synchronization issues in OpenMP is very easy... Automatic locks are provided, u need not to design your own locking mechanisms Just a statement and u can lock the shared variable... Then the major work remains is to identify the shared access. I WANT TO USE OPENMP library. ANY suggestions.
Want to work on Design Development of Squid on Multi-core Architecture. . .
Dear developers, Since last few years i am using squid, Now I want to do some development and want to make squid even better, I have tried to write few lines to introduce myself as follows. Name:Mr. Sachin H. Malave Working under the guidance of Dr. D. B. Kulkarni.(http://hpc.wce.org.in) Country: India Qualifications: M.Tech Student, Computer Science and Engineering Department, Walchand college of engineering, Sangli (http://www.walchandsangli.ac.in), Area of Squid interested in : Design Development of Squid on Multi-core Architecture( Selected as Dissertation work ) Laboratory Setup : 32-core (Quad core, eight AMD opteron processors ) system with 24GB RAM (http://hpc.wce.org.in) More references :http://www.parshvanathengg.com/faculty_COMP/Malave.html Thank you.
